Re: Xorg module searchpath "override" directory
On Tue, Aug 23, 2011 at 11:32:22 +0200, Andreas Beckmann wrote: > Hi all, > > since I didn't get any feedback, yet, I'm asking again. > > Are there any objections to installing the alternative slave link for > vendor implemntations of libglx.so as > /usr/lib/xorg/modules/linux/libglx.so > and leave > /usr/lib/xorg/modules/extensions/libglx.so > undiverted? > According to the source code and my tests, the linux subdirectory is > always searched first for modules and therefore suitable to install > "override modules". > I'd prefer an explicit override directory over abusing 'linux'. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110823093350.gb24...@coloquinte.cristau.org
Re: Xorg module searchpath "override" directory
Hi all,
since I didn't get any feedback, yet, I'm asking again.
Are there any objections to installing the alternative slave link for
vendor implemntations of libglx.so as
/usr/lib/xorg/modules/linux/libglx.so
and leave
/usr/lib/xorg/modules/extensions/libglx.so
undiverted?
According to the source code and my tests, the linux subdirectory is
always searched first for modules and therefore suitable to install
"override modules".
Andreas
On 2011-08-10 23:08, Andreas Beckmann wrote:
> On 2011-07-25 19:03, Julien Cristau wrote:
>> On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote:
>>> libGL.so.1 is not the only file to be diverted, libglx.so is being
>>> replaced by the vendors drivers, too. Or is there some way of "search
>>> path magic" that would allow to place the "higher priority alternative"
>>> in a different location where it would be picked up before
>>> /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
>>> the diversion here. Something similar to /lib/modules/*/updates/ ...
>>>
>> That shouldn't be too hard.
>
> I tried to look in the code (xorg-server (2:1.7.7-13)
> hw/xfree86/loader/* ; the experimental version does not differ much in
> that area) but didn't quite get how the search path is working.
> Therefore I added a bit debugging code to trace FindModuleInSubdir().
> Translating to pseudocode this now looks like
>
> modulepath=/usr/lib/xorg/modules
> for subdir in "" input drivers multimedia extensions internal
> do
> search_recursive ${modulepath}/${subdir}/linux/
> search_recursive ${modulepath}/${subdir}/
> done
>
> So the order the directories are traversed and files are found depends
> on the raw order in the filesystem (opendir()), except for the linux
> subdir which is checked first.
>
> hw/xfree86/loader/loadmod.c has
> /* Standard set of module subdirectories to search, in order of
> preference */
> static const char *stdSubdirs[] = {
> "",
> "input/",
> "drivers/",
> "multimedia/",
> "extensions/",
> "internal/",
> NULL
> };
>
> but since a recursive search is done on "" first, the other directories
> in the list will be traversed (again and without hope of success) only
> if the first search was unsuccessful. So that "order of preference" is
> no more existant and the above pseudocode could be simplified to
>
> modulepath=/usr/lib/xorg/modules
> search_recursive ${modulepath}/linux/
> search_recursive ${modulepath}/
>
>
> Back to the original problem: replacing libglx.so with a vendor
> implementation without using diversions.
> I'd do the following:
>
> * leave /usr/lib/xorg/modules/extensions/libglx.so where it is
> (i.e. no longer divert it)
> * the proprietary drivers register their libglx.so replacement with the
> glx alternative which installs it as a slave link to
> /usr/lib/xorg/modules/linux/libglx.so
> so that it is picked up first and the original one is being ignored
>
> "linux" is acually OSDIR in the code and may have had a different
> intention, but it is the only deterministic place that is searched
> "before" extensions/libglx.so
>
> * no changes in Xorg needed regarding the search paths
> * works on both unstable and squeeze, so backports don't need special
> handling
>
> If this is OK, I'll implement and test it and also verify that Xorg
> works in the same way in testing/unstable/experimental.
> That way, the first of the ugly diversions could be removed. :-)
>
> Andreas
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5373a6.2070...@abeckmann.de
Bug#638965: xserver-xorg-core: add override directory that is prepended to the module search path
Package: xserver-xorg-core Version: 2:1.7.7-13 Severity: wishlist Hi, as this was discussed on the mailing list before, see e.g. [1] http://lists.debian.org/debian-x/2011/08/msg00157.html [2] http://lists.debian.org/debian-x/2011/08/msg00364.html there is need for an override directory that is prepended to the module search path. In [1] I describe my analysis of the current search path system and in [2] Julien says I'd prefer an explicit override directory over abusing 'linux'. An override directory could be used so that vendor implementations of a module (e.g. libglx.so) can be installed installed in the override directory and will be found before the native xorg module without having to use dpkg-divert on the original module. Such a solution would simplify using update-alternatives to enable/disable the vendor implementation without installing/removing packages. For the time being, /usr/lib/xorg/modules/linux/ could be abused for that purpose. Andreas -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110823113812.26681.77327.reportbug@calzone.localnet
Re: Xorg module searchpath "override" directory
On 2011-08-23 11:33, Julien Cristau wrote: > On Tue, Aug 23, 2011 at 11:32:22 +0200, Andreas Beckmann wrote: >> Are there any objections to installing the alternative slave link for >> vendor implemntations of libglx.so as >> /usr/lib/xorg/modules/linux/libglx.so ... > I'd prefer an explicit override directory over abusing 'linux'. OK, just opened wishlist bug #638965 against xserver-xorg-core. http://bugs.debian.org/638965 Until this explicit override directory gets implemented and for squeeze-backports (which needs newer versions of nvidia-graphics-drivers for supporting newer GPUs), would you agree if I use modules/linux for now? That way the first of the diversions can be eliminated and we can go back to the other question "How to reorganize the mesa packages to avoid diversions when installing a vendor libGL.so.1". Andreas -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e53947c.2080...@abeckmann.de
Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card
On Mon, Aug 22, 2011 at 1:38 PM, Willian Gustavo Veiga wrote: > Of course I can Alex. It's attached. > Thank you very much. The radeon has no connectors specified in the vbios so it's muxless. Not much we can do with it until X gets re-architected to decouple display and rendering. Alex -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADnq5_POt4LNh2Rjzn5k3ToCEHY-9iA2hgRBM6_=legzdjf...@mail.gmail.com
Processed: affects 638965, affects 638980
Processing commands for cont...@bugs.debian.org: > affects 638965 src:glx-alternatives Bug #638965 [xserver-xorg-core] xserver-xorg-core: add override directory that is prepended to the module search path Added indication that 638965 affects src:glx-alternatives > affects 638980 src:nvidia-cuda-toolkit Bug #638980 [starpu-contrib] starpu-contrib: cuda/opencl build dependencies need to be limited to [amd64 i386] Added indication that 638980 affects src:nvidia-cuda-toolkit > thanks Stopping processing here. Please contact me if you need assistance. -- 638980: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638980 638965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131410693630380.transcr...@bugs.debian.org
Bug#638978: xorg: X crashes when opening pidgin
On Tue, Aug 23, 2011 at 16:12:29 +0300, Mandrantosoa 'Ndrianiaina wrote: > Package: xorg > Version: 1:7.6+8 > Severity: normal > > When I open pidgin or iceweasel X crash... > > I can work normally when drm is not loaded. > > Joined : my last Xorg.0.log when X crashed. > That doesn't show a crash, it shows X getting stuck sending commands to the GPU via the drm (probably because the GPU hangs). Are you actually seeing X crash, or just not update the display anymore? Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110823173800.gp2...@radis.liafa.jussieu.fr
Bug#638978: xorg: X crashes when opening pidgin
On Die, 2011-08-23 at 16:12 +0300, Mandrantosoa 'Ndrianiaina wrote: > > When I open pidgin or iceweasel X crash... Does this also happen if you boot with radeon.agpmode=1 (or even radeon.agpmode=-1) on the kernel command line? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314121846.21860.314.camel@thor.local
Bug#626682: Side effects are not limited to sylog messages...
Who would have thought of that? >From Keith Packard: > I've merged a fix to master today; I'd love to get a bit of testing > before I finish the (slightly delayed) 1.11 release. http://lists.x.org/archives/xorg-devel/2011-August/024532.html http://cgit.freedesktop.org/xorg/xserver/commit/?id=e32cc0b4c85c78cd8743a6e1680dcc79054b57ce -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAxjCEzGyRQ00H3XbD=PUGe8jY=krr4+6f5mbgebzv23abu...@mail.gmail.com
Bug#637958: X.org crash leaves GPU in an inconsistent state and renders system unbootable
On Thu, 2011-08-18 at 13:10 +0200, Cyril Brulebois wrote: > Martin (18/08/2011): > > The instructions work but the packages will not install due to a > > dependency problem. If I understand correctly what's happening is: > > > > *. Part of the xorg core breaks *-video-6 > > Because src:xorg has not reached squeeze-backports yet. Uploaded a few > hours ago (src:xorg needed to reached testing before it could be > backported, hence the delay compared to mesa, xorg-server, and drivers). > Right; have upgraded to the latest X.org and kernel in backports and the problem still persists. Something causes the machine to hang while bieng used interactively in X and after this loading the kernel psmouse module hangs the machine. What should I try next? Should I move this to being a kernel bug? Cheers, - Martin -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314137680.4074.200.ca...@white.sevalidation.com
Bug#639094: xterm: Middle mouse clip being remembers by Xterm
Package: xterm Version: 261-1 Severity: wishlist Hi, I would like to have easier coding when coping some lines into xterm from gedit. (xclip -o gives you its content, mouse middle click paste it) Then I modify this line of code to my purpose, and press ENTER You might want to modify it and improve your line command, so ok, press UP ARROW KEY. Not working? - really Please add this to another wishlist when you may find little time to add this gorgeous wished feature for coders. Sincerely, Y. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xterm depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libfontconfig12.8.0-2.1 generic font configuration library ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libutempter0 1.1.5-3A privileged helper for utmp/wtmp ii libx11-6 2:1.3.3-4 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii xbitmaps 1.1.0-1Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.5+4 X11 utilities Versions of packages xterm suggests: pn xfonts-cyrillic(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824014049.3149.47255.report...@debian05.lan
Bug#639097: wishlist: easier configuration for several Displays
Package: xdm Version: 1:1.1.10-3 Severity: wishlist Hi Xdm, I would like to give a few wishlist. The output of the command returns : $ less X11/xdm/xdm-config ! ! ! ! ! DisplayManager.authDir: /var/lib/xdm DisplayManager.errorLogFile:/var/log/xdm.log DisplayManager.pidFile: /var/run/xdm.pid DisplayManager.keyFile: /etc/X11/xdm/xdm-keys DisplayManager.servers: /etc/X11/xdm/Xservers DisplayManager.accessFile: /etc/X11/xdm/Xaccess DisplayManager*resources: /etc/X11/xdm/Xresources DisplayManager.willing: su nobody -c /etc/X11/xdm/Xwilling ! All displays should use authorization, but we cannot be sure ! X terminals will be configured to support it, so those that do not will ! require individual resource settings. DisplayManager*authorize: true ! DisplayManager*chooser: /usr/lib/X11/xdm/chooser DisplayManager*startup: /etc/X11/xdm/Xstartup DisplayManager*session: /etc/X11/xdm/Xsession DisplayManager*setup: /etc/X11/xdm/Xsetup DisplayManager*reset: /etc/X11/xdm/Xreset DisplayManager*authComplain:true DisplayManager*loginmoveInterval: 10 ! SECURITY: do not listen for XDMCP or Chooser requests ! Comment out this line if you want to manage X terminals with xdm DisplayManager.requestPort: 0 X11/xdm/xdm-config (END) This file is actually the config. For users that would like to have xdm running onto :0 :1 and :2, the "DisplayManager.requestPort: 0" is quite obscur for understanding. Into GDM configuration it was more straightforward to understand what it mean and how to add additional :0 :1 .. gdm. Please could you update the config making it easier to modify. Actually to set up : :0 ... until :6, shall I use "DisplayManager.requestPort: 1" ... DisplayManager.requestPort: 6 ? Thanks for maintaining XDM ! Its light, it rocks, and we need solutions ligthweight simple like XDM !! Thank you very much ! Yellow -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xdm depends on: ii cpp 4:4.4.5-1The GNU C preprocessor (cpp) ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libpam0g1.1.1-6.1Pluggable Authentication Modules l ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii libx11-62:1.3.3-4X11 client-side library ii libxau6 1:1.0.6-1X11 authorisation library ii libxaw7 2:1.0.7-1X11 Athena Widget library ii libxdmcp6 1:1.0.3-2X11 Display Manager Control Protoc ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxinerama12:1.1-3 X11 Xinerama extension library ii libxmu6 2:1.0.5-2X11 miscellaneous utility library ii libxpm4 1:3.5.8-1X11 pixmap library ii libxrender1 1:0.9.6-1X Rendering Extension client libra ii libxt6 1:1.0.7-1X11 toolkit intrinsics library ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii procps 1:3.2.8-9/proc file system utilities ii x11-common 1:7.5+8 X Window System (X.Org) infrastruc ii x11-utils 7.5+4X11 utilities ii x11-xserver-utils 7.5+3X server utilities xdm recommends no packages. xdm suggests no packages. -- debconf information: xdm/stop_running_server_with_children: false xdm/daemon_name: /usr/bin/xdm * shared/default-x-display-manager: xdm -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824025744.21532.4809.report...@debian05.lan
Bug#637958: X.org crash leaves GPU in an inconsistent state and renders system unbootable
On Die, 2011-08-23 at 23:14 +0100, Martin wrote: > On Thu, 2011-08-18 at 13:10 +0200, Cyril Brulebois wrote: > > Martin (18/08/2011): > > > The instructions work but the packages will not install due to a > > > dependency problem. If I understand correctly what's happening is: > > > > > > *. Part of the xorg core breaks *-video-6 > > > > Because src:xorg has not reached squeeze-backports yet. Uploaded a few > > hours ago (src:xorg needed to reached testing before it could be > > backported, hence the delay compared to mesa, xorg-server, and drivers). > > > > Right; have upgraded to the latest X.org and kernel in backports and the > problem still persists. Something causes the machine to hang while > bieng used interactively in X and after this loading the kernel psmouse > module hangs the machine. > > What should I try next? Can you try if the hangs in X happen when the psmouse module is never loaded in the first place? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314168602.21860.329.camel@thor.local
