openSUSE X.org June 2012

xorg@lists.opensuse.org

9 participants
8 discussions

[opensuse-xorg] Re: [Bug 766513] (global X configuration logistics)
by Felix Miata 09 Aug '12

09 Aug '12

On 2012/06/18 10:31 (GMT) bugzilla_noreply(a)novell.com composed: > https://bugzilla.novell.com/show_bug.cgi?id=766513 > https://bugzilla.novell.com/show_bug.cgi?id=766513#c12 > --- Comment #12 from Stefan Dirsch<sndirsch(a)suse.com> 2012-06-18 10:31:52 UTC --- (In reply to comment #12) > (In reply to comment #11) > > Which "above"? > I've meant my commment above. Obviously "above", but which "above", 8? 7? That response was to comment 9's "Since post-comment 7 zypper dup on both i845G hosts, KDE does run, but with everything unusably small due to lack of the required content from those files", which I fully expected when written to get no response to. Because I did get an apparent response, I tried to figure out how anything you wrote previously was even related, much less answered, but failed to do so. > > Are you suggesting I should go back to the more difficult use of > > an xorg.conf file to globally control VertRefresh, DisplaySize, panning, etc., > > and leave xorg.conf.d/ content up to the package management system, that /etc > > isn't for global user configs any more? > That's the way it is done now, for corner cases like you always have with your > prehistoric hardware. Again your response as directly relates to my question is ambiguous. I still can't ascertain from your responses whether I am expected to be using xorg.conf or xorg.conf.d/ to globally force text and icons on a GUI desktop to a size legible for those with 25th or lower percentile vision; those who find it difficult to use X configuration tools to do the same on account of the chicken and egg nature of the situation caused in part by escalating physical display pixel density, X settings fonts in fact 7pt or less faced by those who require 10pt or more just to discern, much less be comfortable using. Not so many releases back, openSUSE had been using (10pt in KDE; elsewhere?) system and menu fonts, larger than most other distros (*buntu, Fedora, Mandriva: 9pt). Then openSUSE dropped them down to match the competition, removing yet another superior openSUSE feature. Devs with teenage eyesight (apparently most software and web site devs) don't get that people with poorer vision find it hard to make things bigger, especially since the death of SaX2 and new, resolution-flexible CRTs, in contrast to the ease with which those with good vision can make them smaller. As to "prehistoric": I certainly do not represent the majority of developers (or maybe all?), who apparently upgrade their hardware every generation or two, or more often, as many must to support new hardware as it becomes available. I represent those whose upgrade cycle is from 10, 12 or 15 year old systems to functional 6, 8 or 10 year old systems originally acquired during a period when vendors no longer shipped Windows media with each PC, leaving acquirers of used PCs or their original owners unable to legally reinstall the OEM OS on a new HD; hardware long out of use by most if not all devs, but legitimate for use of a FOSS OS intended in part to expand access to the internet to the financially challenged. Contrary to the opinions of many devs and users jaded by the speed and RAM supply of newer hardware, those who know no better can nevertheless still find KDE @600 MHZ with 384M of RAM usable. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

4 7

[opensuse-xorg] twm & xdm installed by xorg-x11 regardless
by Felix Miata 28 Jun '12

28 Jun '12

I've been doing only minimal installs of Factory lately. I also set solver.onlyRequires=true and use only zypper for package management. That means patterns shouldn't be installed, yet they seem to be anyway. Today I notice on such an rv380 installation that I had incompletely installed Xorg even though KDE 4.8.4 works using startx, but KDM didn't, and still doesn't for reasons unknown to me. In trying to get KDM to work I noticed xorg-x11 hadn't been installed, so I did zypper in xorg-x11. That resulted in 4 packages to install, including twm and xdm. Why on a system with kdm already installed are twm and xdm required? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

2 4

[opensuse-xorg] XOrg deadlock in a multi-threaded X app that works on FC/RHEL distributions
by Myrosia Dzikovska 26 Jun '12

26 Jun '12

I am trying to get a library (written by someone else) to run on OpenSuse 12.1; I am not an X developer, but I inherited it and need things to run. The library is tested and runs on FC13, RHEL 5 and SL6 without problems. But it consistently creates deadlocks in X calls on OpenSuse 12.1 The sequence of events is 1. XInitThreads is called 2. The library creates a thread ("XEventThread") and starts executing it. The thread executes a simple loop that repeatedly calls XNextEvent and passes the returned events elsewhere. 3. XEventThread calls XNextEvent 4. XNextEvent blocks waiting for events; it does not return immediately because there are no windows yet 5. XEventThread releases control to the main app thread 6. the main app thread calls XLockScreen 7 the main app thread starts creating windows 8. The first call to X functions, e.g. XCreateSimpleWindow, hangs This is with XSyncrhonize enabled; if it is disabled, a few X calls will succeed, but eventually something will hang forever. On the OSes that work (FC13, ScientificLinux 6) the difference is point 8 - the calls to X never lock, everything proceeds happily. It works with a variety of window managers. Why is there a difference on the OpenSuse, and what can I do about it? I am happy to file a bug report with Novell, too, if this appears to be a bug. I originally asked a version of this question on the general X list (well, it started less clearly defined), and got a suggestion that this may be a thread safety fix missing from OpenSuse XLib. http://lists.freedesktop.org/archives/xorg/2012-June/054726.html I also created a cut-down version of the library (in the attached file) that displays the behaviour. On FC13 and RHEL it creates 3 windows with 3-second intervals between them, and then waits forever. It succeeds every time. On OpenSuse 12.1 it freezes as soon as the thread starts, usually on the first call to XCreateSimpleWindow during the creation of the first window. It is not affected by a window manager - fails for all of them. To compile gcc -O2 -ansi -g -DXGRAFIX -I. -DUNIX -D_cplusplus -D_XOPEN_SOURCE=500 -D_REENTRANT -c -o HGraf.o HGraf.c gcc HGraf.o -lpthread -lm -lX11 -L/usr/X11R6/lib mv a.out HGrafTest to run ./HGrafTest Is this indeed an OpenSuse bug, or am I missing something about the program? Thanks, Myrosia

4 6

[opensuse-xorg] Huge problems with glamor since intel 2.19.0 driver switch in XOrg repo
by Dr. Ralf Czekalla 16 Jun '12

16 Jun '12

Since the switch to intel driver 2.19.0 a week ago or so, I have huge problems to start X now. I always get this error message during start-up: [ 40.415] (II) Loading /usr/lib64/xorg/modules/extensions/libdri2.so [ 40.451] (II) Module dri2: vendor="X.Org Foundation" [ 40.451] compiled for 1.12.2, module version = 1.2.0 [ 40.451] ABI class: X.Org Server Extension, version 6.0 [ 40.451] (II) Loading extension DRI2 [ 40.451] (II) LoadModule: "glamoregl" [ 40.470] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 41.442] (EE) Failed to load /usr/lib64/xorg/modules/libglamoregl.so: /usr/lib64/xorg/modules/libglamoregl.so: undefined symbol: _glapi_tls_Context [ 41.442] (II) UnloadModule: "glamoregl" [ 41.442] (II) Unloading glamoregl [ 41.442] (EE) Failed to load module "glamoregl" (loader failed, 7) ... [ 41.503] (II) Loading extension XFree86-DRI [ 41.503] (II) LoadModule: "intel" [ 41.503] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 41.541] (EE) Failed to load /usr/lib64/xorg/modules/drivers/intel_drv.so: libglamor.so: cannot open shared object file: No such file or directory [ 41.541] (II) UnloadModule: "intel" [ 41.541] (II) Unloading intel [ 41.541] (EE) Failed to load module "intel" (loader failed, 7) [ 41.541] (EE) No drivers available. Why is this? Any suggestions? Currently installed is: xf86-video-intel-2.19.0_20120601_8eed569-15.1.x86_64.rpm <http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.1/x86_64/xf…> from http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.1/x86_64 And this is the i5-680 CPU which is used for X: [ 40.343] (--) PCI:*(0:0:2:0) 8086:0042:1458:d000 rev 24, Mem @ 0xfb400000/4194304, 0xc0000000/268435456, I/O @ 0x0000ff00/8 I searched for similar errors, found also some rare messages about_glapi_tls_Context in combination with glamor, but nothing fits or it's combined with Mesa. The latter offered some changes in glamor.conf to do the loading of libs in the right order (glamor before Mesa). I tried this but it didn't change the error message above. Thanks Ralf -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

3 5

[opensuse-xorg] Mesa/Gallium3D: enabling build flags for XvMC & VDPAU state trackers
by Tyler 15 Jun '12

15 Jun '12

Hi, Not sure if this is the appropriate list to write too -- I realize that Mesa falls outside of Xorg, though its heavily related to some of the xorg elements. Anyway, given the absence of /usr/lib64/libXvMCr600.so and /usr/lib64/vdpau/libvdpau_r600.so from the package provided by either the repos for 12.1 or factory, it appears that Mesa isn't being compiled with the build flags being enabled for the XvMC & VDPAU state trackers. Rather obviously (from my missing files mention above) I'm looking to use these features with the r600g driver for an AMD video adapter. The XvMC state tracker is strictly MPEG1/2 decode support. The VDPAU state tracker, as well, currently only supports MPEG1/2 decode, though (hopefully) this will eventually be extend to support other formats. While MPEG2 decode support might seem rather pedestrian to some, it is beneficial to many others (Example: the ATSC digital TV system uses MPEG2 formatting for channels streams). In addition, users of hardware supported by the r300g and nouveau drivers would also be able to make use of the state trackers. Is there any reason why mesa isn't being built with those features enabled ? Or, more to the point, could they be enabled for the mesa package in factory so that users can take advantage of them (if they so choose and/or is useful to them)? TIA -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

2 4

[opensuse-xorg] Panning is broken
by Felix Miata 12 Jun '12

12 Jun '12

Upstream: https://bugs.freedesktop.org/show_bug.cgi?id=39949 Looks like it could use some help from anyone capable. It was reported 10 months ago. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

2 3

[opensuse-xorg] led display Suppliers shared photos with you
by led display Suppliers 10 Jun '12

10 Jun '12

Dear Mr/Miss, Still be puzzling about looking for best led display supplier? Now it will be miles easier working with KEROSA! Here you can find competitive price and excellent quality with a best mix. We"ve been in led display career for many years. We know your market and your country well. Our business is flexible which something is more likely to be a friend chat. We never waste your time. Our conversation will be very efficient base on our good communication. Please reply as soon as possible .if you are working on some led display project. We are ready to make you a satisfied offer! Samuel Shezhen Krosa Techology Co.,Ltd. Address: Building 3,Park,Guanguang road,Bao"an District,Shenzhen,China. post 518000

1 0

[opensuse-xorg] Is i915 driver working on i915 chip (or Iany?) for anyone running 12.2B1?
by Felix Miata 08 Jun '12

08 Jun '12

I don't see an existing filed bug about this. 11.4 and 12.1 work fine @ 1600x1200 on i915 on same machine. Several lines with 915 show up in lsmod output, but without glamor I can't seem to find any way to not have Xorg use only FBDEV driver, either with current 3.4 desktop kernel or the 3.4rc2 one last installed 7 weeks ago. Xorg.0.log: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-gx280-i915-122B1-FBDEV.txt Highlight in there: (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: libglamor.so: cannot open shared object file: No such file or directory With glamor installed I get segfault trying to start Xorg: [ 181.126] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server, Ivybridge Server (GT2) [ 181.127] (II) FBDEV: driver for framebuffer: fbdev [ 181.127] (II) VESA: driver for VESA chipsets: vesa [ 181.127] (--) using VT number 2 [ 181.137] [ 181.137] Backtrace: [ 181.154] 0: X (xorg_backtrace+0x49) [0x81bc599] [ 181.154] 1: X (0x8048000+0x178206) [0x81c0206] [ 181.154] 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb770140c] [ 181.154] 3: X (xf86nameCompare+0x55) [0x80e8815] [ 181.154] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb6d20000+0xb515) [0xb6d2b515] [ 181.154] 5: X (0x8048000+0x8c5ed) [0x80d45ed] [ 181.154] 6: X (xf86CallDriverProbe+0xac) [0x80b0dec] [ 181.154] 7: X (xf86BusConfig+0x94) [0x80b1714] [ 181.154] 8: X (InitOutput+0x829) [0x80be5d9] [ 181.154] 9: X (0x8048000+0x20f96) [0x8068f96] [ 181.154] 10: /lib/libc.so.6 (__libc_start_main+0xf5) [0xb725a3d5] [ 181.155] 11: X (0x8048000+0x214a9) [0x80694a9] [ 181.155] [ 181.155] Segmentation fault at address (nil) [ 181.155] Fatal server error: [ 181.155] Caught signal 11 (Segmentation fault). Server aborting -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-xorg+owner(a)opensuse.org

1 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

openSUSE X.org June 2012