xkbcomp broken - (EE) XKB: Couldn't compile keymap
This error shows up yesterday after updating xkbcomp to the latest git version. (EE) Error compiling keymap (server-0) (EE) XKB: Couldn't compile keymap (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap Bisected and reverting this commit fixed the problem. Without reverting, functions keys will not work in fvwm. 37b62a26716d3abf2ae07dd88cf54bc04d980bd8 is first bad commit commit 37b62a26716d3abf2ae07dd88cf54bc04d980bd8 Author: Alan Coopersmith <[EMAIL PROTECTED]> Date: Fri Sep 5 14:22:33 2008 -0700 Check for strdup & strcasecmp before assuming we need to provide our own Thanks, Jeff. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Mon, Sep 8, 2008 at 11:58 PM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > Hi, > > Keith talked me intro writing a spec for DRI2, which I grudgingly must > admit is a good idea. I used the randr spec as a template, except I > replaced the flowery section dividers with a more fitting gears motif. > It's still a work in progress, mostly the introductory/background > sections though. The requests and wire encoding sections are mostly > complete and is close to what's in the git repos at this point. The > implementation isn't fully uptodate with the spec yet, but I figured > it would be wise to circulate the spec before doing more code churn, > so here it is. > In section 10, XvMC is mentioned, but this could apply to Xv as well. FWIW I think it makes a lot of sense to do that, mostly for performance reasons (YUV data is usually 12 bit per pixel, if we add a RGBA 32 bit per pixel copy on top of that it's definitely not negligible). Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, Sep 9, 2008 at 7:51 PM, Keith Packard <[EMAIL PROTECTED]> wrote: >> That mechanism could be basically the same as the existing >> sync-to-vblank mechanisms, but with 'vertical blank' replaced by >> 'compositing manager screen update'. So it would provide the client with >> a way to express the display frame at which the buffer swap should take >> effect and to synchronize to the compositing manager making it so. > > We chatted about this and Kristian suggested that we would throttle the > app to vblank rate, rather than compositing manager rate. On second > thought, perhaps driving this from the compositing manager would make > sense. I think is makes more sense if the composite manager initiates the vsync because only the composite manager can insert the sync at coherent points (in the case of single buffering that's useful). Also this leaves more flexibility for composite managers to act as they like. Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help?
On Tue, Sep 09, 2008 at 02:00:09PM -0700, Markus Strobl wrote: > You can have fglrx installed, there's no problem with that. But fglrx cannot > be LOADED when you try loading radeon. So check if fglrx has loaded with > lsmod. If it is, remove it from the kernel (rmmod fglrx) and try starting X > again. > > Disclaimer: The above is based on my experiences using Gentoo, not Ubuntu... > both my Ubuntu machines have NVidea cards in them. That is indeed specific to Gentoo and the exact opposite of the situation with Ubuntu and Debian. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Strobl wrote: > Hi, > > You can have fglrx installed, there's no problem with that. But fglrx cannot > be LOADED when you try loading radeon. So check if fglrx has loaded with > lsmod. If it is, remove it from the kernel (rmmod fglrx) and try starting X > again. > > Disclaimer: The above is based on my experiences using Gentoo, not Ubuntu... > both my Ubuntu machines have NVidea cards in them. fglrx taints the kernel when loaded, and in my experience, can mess up kernel memory if one tries to load radeon after "rmmod fglrx". My suggestion? Blacklist, rename, or delete your fglrx.ko . Of course, if merely removing it from the kernel works for you, then go with that. :3 ~ C. - -- ~ Corbin Simpson <[EMAIL PROTECTED]> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjG6Z8ACgkQeCCY8PC5utBP6QCggXvEbYzYuTsMdumW1K9URNJp A4YAoI2Bw676bJhSTG0IuWHY14yM5wwX =hhpF -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help?
On Tue, Sep 09, 2008 at 06:54:32PM +0200, Lars Oliver Hansen wrote: > I have indeed fglrx installed for the Ubuntu kernel (bootable from a > second grub entry). Is libGL made up by the _dri.so files or is > libGL another file collection? My r300_dri.so is from a package by > Andrius Štikonas which contains a backport of mesa with fixes by David > Airlie for the Radeon XPress 1100 to work with DRI > http://ppa.launchpad.net/stikonas/ubuntu and > http://airlied.livejournal.com/59351.html . That package I installed > after fglrx. Would uninstalling fglrx solve the problem or would I have > to get another mesa (which includes libGL if I understood you right)? If you've just installed packages, then uninstalling fglrx is fine. If you installed it manually, you'll need to reinstall Mesa from the packages also (sudo apt-get install --reinstall libgl1-mesa-glx on Debian/Ubuntu). 'libGL' in this sense refers to libGL.so (usually in /usr/lib). Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help?
Hi, You can have fglrx installed, there's no problem with that. But fglrx cannot be LOADED when you try loading radeon. So check if fglrx has loaded with lsmod. If it is, remove it from the kernel (rmmod fglrx) and try starting X again. Disclaimer: The above is based on my experiences using Gentoo, not Ubuntu... both my Ubuntu machines have NVidea cards in them. HTH, Markus - Original Message From: Lars Oliver Hansen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Tuesday, September 9, 2008 11:54:32 AM Subject: Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help? Hi Markus, Julien and Daniel! Thanks for your answers! I have indeed fglrx installed for the Ubuntu kernel (bootable from a second grub entry). Is libGL made up by the _dri.so files or is libGL another file collection? My r300_dri.so is from a package by Andrius Štikonas which contains a backport of mesa with fixes by David Airlie for the Radeon XPress 1100 to work with DRI http://ppa.launchpad.net/stikonas/ubuntu and http://airlied.livejournal.com/59351.html . That package I installed after fglrx. Would uninstalling fglrx solve the problem or would I have to get another mesa (which includes libGL if I understood you right)? Thanks and K&BR Lars Am Dienstag, den 09.09.2008, 01:15 +0300 schrieb Daniel Stone: Usually, this indicates that you still have fglrx installed. Even if you're not using it, fglrx provides its own libGL.so which is incompatible with Mesa's, so you have to remove it before you can use the open source driver. Cheers, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Device Properties Protocol Spec - Draft 1
Peter Hutterer wrote: > On Mon, Sep 08, 2008 at 11:19:21AM +0200, Simon Thum wrote: >> unexposed flag. Could be BadValue vs. BadMatch, but I'm missing it in >> the ChangeDeviceProperty spec (readonly is arguably a type mismatch). > > we could do that as BadAccess, though I'm not sure how that'd mingle with the > security stuff. Judging from X.h, BadAccess is already quite context-dependent. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tue, 9 Sep 2008, Yan Seiner wrote: > How do I go about notifying all users? I am looking for an equivalent > of 'wall' for X. xmessage doesn't really work very well as I'd have to mess > with xhost in each user's profile. > > I've looked at libnotify, but it runs into dbus security issues. > > So how does a sysadmin notify all users of an impending system event (like a > shutdown)? use g-message (which relies on notify-send): http://soleup.eup.uva.es/trac/browser/scripts/g-message works here.. t ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tuesday 09 September 2008 09:25:13 am John Tapsell wrote: > 2008/9/9 Jason Kim <[EMAIL PROTECTED]>: > > I think the imaginary "xwall" won't work because each user has it's own > > X session. > > > > How possibly a program determine all running X sessions? > > KDE used to have a demon 'kwrited' that would simply listen for > 'wall' messages and then display them to the user. > > This code probably just needs a bit of cleaning up and would probably > work again. > > Something similar could be done for gnome > > JohnFlux I just did a quick test with KDE 4.1 and kwrited is working and popping up a message box that has messages sent with wall. So it is working at least for more recent versions of KDE. I would think that the daemon could be modified without too much difficulty to pop up a generic X (IE. non-KDE or Qt specific) message box if that is not already the case. To configure this go to System Settings --> Advanced --> Service Manager and make sure that KDE Write Daemon is checked in the Startup Services area. Hal ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 19:34 +0200, Michel Dänzer wrote: > On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote: > > On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > > > > > GLX_EXT_texture_from_pixmap needs the real front buffer. > > > > Sure, but that's not through DRI2, this just references the object as an > > X pixmap. > > I don't understand what you mean. How would a direct rendering, > zero-copy implementation of GLX_EXT_texture_from_pixmap work without > getting the pixmap buffer ID via DRI2GetBuffers? I assumed that GLX would do this part of the protocol, not DRI2; probably just a misunderstanding of how this all works at a protocol level though. > So in order to find out the effective sequence number, the client would > need to keep incrementing the target number and check for the error? > Doesn't sound very appealing to me. Yeah, the protocol doesn't exactly provide any way of knowing what the current vblank sequence number is. > Not to mention X protocol errors tend to be a PITA. In what way? > That mechanism could be basically the same as the existing > sync-to-vblank mechanisms, but with 'vertical blank' replaced by > 'compositing manager screen update'. So it would provide the client with > a way to express the display frame at which the buffer swap should take > effect and to synchronize to the compositing manager making it so. We chatted about this and Kristian suggested that we would throttle the app to vblank rate, rather than compositing manager rate. On second thought, perhaps driving this from the compositing manager would make sense. Somehow we'd have to connect compositing manager operations to specific client actions though; I'm not sure we've got protocol to do that at this point. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote: > On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > > > GLX_EXT_texture_from_pixmap needs the real front buffer. > > Sure, but that's not through DRI2, this just references the object as an > X pixmap. I don't understand what you mean. How would a direct rendering, zero-copy implementation of GLX_EXT_texture_from_pixmap work without getting the pixmap buffer ID via DRI2GetBuffers? > > Some GLX synchronization extensions provide information about whether a > > buffer swap hit or missed the target. > > We could have the request return an error if the sequence target could > not be met. So in order to find out the effective sequence number, the client would need to keep incrementing the target number and check for the error? Doesn't sound very appealing to me. Not to mention X protocol errors tend to be a PITA. > > Generally, if DRI2CopyRegion seriously wants to be useful for > > synchronization purposes, it probably needs to provide at least the same > > functionality as the DRM vblank related ioctls. > > Certainly the combination of DRI2CopyRegion and DRM should be able to > provide sufficient synchronization. The question is what portion of this > task belongs in the extension and what portion belongs in the DRM kernel > API. If the GLX implementation is to use DRI2CopyRegion for synchronization purposes, then the interface of the latter needs to be at least as expressive as the DRM synchronization interfaces currently used by the former. > > Of course, for redirected windows it should really synchronize to the > > compositing manager rather than to the display hardware directly, but > > I'm not sure that matters at this point. > > For redirected windows, the CopyRegion will not block, and the > compositing manager will get a Damage event when it occurs. At that > point, it's up to the compositing manager to 'do the right thing' to get > contents sync'd to the screen (presumably by using CopyRegion itself). Eventually there will need to be some kind of synchronization mechanism between direct rendering clients and the compositing manager, or smooth animation at the display framerate isn't possible with redirected windows. That mechanism could be basically the same as the existing sync-to-vblank mechanisms, but with 'vertical blank' replaced by 'compositing manager screen update'. So it would provide the client with a way to express the display frame at which the buffer swap should take effect and to synchronize to the compositing manager making it so. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > Sounds like the DRI1 authentication mechanism. :) I don't know how DRI1 works... But, what I do want is a cookie of size sufficient to avoid any potential for security compromise. 32 bits doesn't seem like enough to me. > GLX_EXT_texture_from_pixmap needs the real front buffer. Sure, but that's not through DRI2, this just references the object as an X pixmap. > Consider me convinced that it doesn't need to return any position > information though. Cool. > Some GLX synchronization extensions provide information about whether a > buffer swap hit or missed the target. We could have the request return an error if the sequence target could not be met. > Rather driconf vblank_mode=3. Hmm, though that would also require > DRI2CopyRegion not to execute the copy if the target was missed... Returning an error would make this possible. > Generally, if DRI2CopyRegion seriously wants to be useful for > synchronization purposes, it probably needs to provide at least the same > functionality as the DRM vblank related ioctls. Certainly the combination of DRI2CopyRegion and DRM should be able to provide sufficient synchronization. The question is what portion of this task belongs in the extension and what portion belongs in the DRM kernel API. > Of course, for redirected windows it should really synchronize to the > compositing manager rather than to the display hardware directly, but > I'm not sure that matters at this point. For redirected windows, the CopyRegion will not block, and the compositing manager will get a Damage event when it occurs. At that point, it's up to the compositing manager to 'do the right thing' to get contents sync'd to the screen (presumably by using CopyRegion itself). This has gotten me thinking that we've now made vblank syncing possible for DRM applications but not for 'normal' applications. It seems like we'd really like non-DRM (X-based) compositing managers to get the same benefits here. I'd say we should add a vblank sync'd CopyArea to XFixes at the same time? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 12:55 -0400, Adam Jackson wrote: > On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > > On Tue, 2008-09-09 at 08:46 -0700, Keith Packard wrote: > > > On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: > > > > I do wonder if DRI2GetBuffers should return the drawable position > > > > relative to the origin of each buffer... guess it isn't strictly > > > > necessary except maybe for the real frontbuffer. > > > > > > One of the requirements in DRI2 is that the 'real' front buffer be > > > invisible to applications; there's no way the application can sensibly > > > use those contents. Moreover, the drawable position may change without > > > any warning due to window configuration. > > > > GLX_EXT_texture_from_pixmap needs the real front buffer. > > It does? Texturing from a raw window isn't legal. And if you texture > from a pixmap named with NameWindowPixmap, you get the offscreen > storage, not the composited result in the root window's pixmap. (In > particular, NameWindowPixmap doesn't work on non-redirected windows.) The compositing manager creates the GLXPixmap from the pixmap, not the window. Surely it wants the actual pixmap contents rather than a fake front buffer with random garbage. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
If you know the DISPLAY of all X sessions, then it should be very simple with a script using zenity I guess. On Tue, 2008-09-09 at 09:56 -0700, Yan Seiner wrote: > On Tue, September 9, 2008 9:36 am, Jason Kim wrote: > > Is this only for single computer ? If then, why does people need to show > > message on same computer? > > > > I thought this is for multiple users using their own computer, and admin > > want to notify some messages to everybody. > > Multiseat, XDMCP > > Multiple sessions on the same computer. OTOH the script I cribbed and > modified could be used via ssh to notify other users. > > --Yan > -- *** Jason Kim, Software Developer http://userful.com 2nd Floor, 928-6th Ave SW Calgary, AB T2P 0V5 Tel: 403-289-2177 EXT: 210 866-USERFUL (873-7385) Fax: 403-206-7010 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tue, September 9, 2008 9:36 am, Jason Kim wrote: > Is this only for single computer ? If then, why does people need to show > message on same computer? > > I thought this is for multiple users using their own computer, and admin > want to notify some messages to everybody. Multiseat, XDMCP Multiple sessions on the same computer. OTOH the script I cribbed and modified could be used via ssh to notify other users. --Yan -- o__ ,>/'_ o__ (_)\(_),>/'_o__ Yan Seiner (_)\(_) ,>/'_ o__ Personal Trainer (_)\(_),>/'_o__ Professional Engineer (_)\(_) ,>/'_ Who says engineers have to be pencil necked geeks? (_)\(_) As long as nobody gets hurt, a decent explosion livens up any experiment. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > On Tue, 2008-09-09 at 08:46 -0700, Keith Packard wrote: > > On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: > > > I do wonder if DRI2GetBuffers should return the drawable position > > > relative to the origin of each buffer... guess it isn't strictly > > > necessary except maybe for the real frontbuffer. > > > > One of the requirements in DRI2 is that the 'real' front buffer be > > invisible to applications; there's no way the application can sensibly > > use those contents. Moreover, the drawable position may change without > > any warning due to window configuration. > > GLX_EXT_texture_from_pixmap needs the real front buffer. It does? Texturing from a raw window isn't legal. And if you texture from a pixmap named with NameWindowPixmap, you get the offscreen storage, not the composited result in the root window's pixmap. (In particular, NameWindowPixmap doesn't work on non-redirected windows.) - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.27-rc5 radeon kernel module can't load r300_dri.so - help?
Hi Markus, Julien and Daniel! Thanks for your answers! I have indeed fglrx installed for the Ubuntu kernel (bootable from a second grub entry). Is libGL made up by the _dri.so files or is libGL another file collection? My r300_dri.so is from a package by Andrius Štikonas which contains a backport of mesa with fixes by David Airlie for the Radeon XPress 1100 to work with DRI http://ppa.launchpad.net/stikonas/ubuntu and http://airlied.livejournal.com/59351.html . That package I installed after fglrx. Would uninstalling fglrx solve the problem or would I have to get another mesa (which includes libGL if I understood you right)? Thanks and K&BR Lars Am Dienstag, den 09.09.2008, 01:15 +0300 schrieb Daniel Stone: > Usually, this indicates that you still have fglrx installed. Even if > you're not using it, fglrx provides its own libGL.so which is > incompatible with Mesa's, so you have to remove it before you can use > the open source driver. > > Cheers, > Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 08:46 -0700, Keith Packard wrote: > On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: > > > I think it'd be good if the authentication stuff could be made/kept > > optional or at least not DRM specific. (I'm not sure GEM or the DRM in > > general is within scope of this spec at all) > > I have to admit that I'm not very excited by the existing authentication > protocol. > > What we want is a way to let applications identify themselves with the > kernel and 'prove' that they have permission to access kernel objects. > > It seems like having the X server return a 'cookie' that the client > could use with the kernel module might make things simpler: Sounds like the DRI1 authentication mechanism. :) > > I do wonder if DRI2GetBuffers should return the drawable position > > relative to the origin of each buffer... guess it isn't strictly > > necessary except maybe for the real frontbuffer. > > One of the requirements in DRI2 is that the 'real' front buffer be > invisible to applications; there's no way the application can sensibly > use those contents. Moreover, the drawable position may change without > any warning due to window configuration. GLX_EXT_texture_from_pixmap needs the real front buffer. Consider me convinced that it doesn't need to return any position information though. > > This request also still seems to be missing > > return values for the sequence number when the copy is expected to take > > place and tokens for synchronization of direct rendering to the > > source/destination buffer. > > Eliminating the reply avoids a round trip, so I'm in favor of not > providing any if it's not strictly necessary. > > I don't know if the GL api requires us to provide the expected sequence > number back to the application. Some GLX synchronization extensions provide information about whether a buffer swap hit or missed the target. > For synchronization, we should expect the kernel module to perform this > automatically -- once the X server has processed this request, the > kernel can pend further rendering to the source buffer until the copy > has finished. That would, of course, require that the application know > that the kernel has received the copy command from the X server -- so > the client would need to get something from X server indicating that it > had finished processing the Copy request. The easiest thing to use would > be a reply, but we'd structure the library so that the client wouldn't > pend on the reply and could block just before touching the back buffer > again. Yeah, something like that could work. > > Oh, and I think it should take relative > > sequence numbers as well as absolute ones. > > Yeah, GL does kinda require this. Rather driconf vblank_mode=3. Hmm, though that would also require DRI2CopyRegion not to execute the copy if the target was missed... Generally, if DRI2CopyRegion seriously wants to be useful for synchronization purposes, it probably needs to provide at least the same functionality as the DRM vblank related ioctls. Of course, for redirected windows it should really synchronize to the compositing manager rather than to the display hardware directly, but I'm not sure that matters at this point. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Is this only for single computer ? If then, why does people need to show message on same computer? I thought this is for multiple users using their own computer, and admin want to notify some messages to everybody. On Tue, 2008-09-09 at 17:25 +0100, John Tapsell wrote: > 2008/9/9 Jason Kim <[EMAIL PROTECTED]>: > > I think the imaginary "xwall" won't work because each user has it's own > > X session. > > > > How possibly a program determine all running X sessions? > > KDE used to have a demon 'kwrited' that would simply listen for > 'wall' messages and then display them to the user. > > This code probably just needs a bit of cleaning up and would probably > work again. > > Something similar could be done for gnome > > JohnFlux > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -- *** Jason Kim, Software Developer http://userful.com 2nd Floor, 928-6th Ave SW Calgary, AB T2P 0V5 Tel: 403-289-2177 EXT: 210 866-USERFUL (873-7385) Fax: 403-206-7010 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tue, September 9, 2008 8:51 am, Bill Crawford wrote: > On 09/09/2008, Yan Seiner <[EMAIL PROTECTED]> wrote: > ... >> Because most of my users will not have a terminal session open. >> Typically >> they use a browser full-screen, so I need a popup to notify them. > > Spawn a sub-shell for each user, run "sudo -u $user zenity --warning > 'about to reboot'" ... ? (it should work, tested here on F8). Barely tested xwall based on libnotify. Should work for xfce4 sessions; change the second line to look for gnome, kde, etc. #!/bin/sh pids=`pgrep xfce4-session` title=$1 text=$2 timeout=$3 echo $pids if [ -z "$title" ]; then echo You need to give me a title >&2 exit 1 fi if [ -z "$text" ]; then text=$title fi if [ -z "$timeout" ]; then timeout=6 fi for pid in $pids; do # find DBUS session bus for this session DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \ /proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'` UNAME=`grep -z USERNAME \ /proc/$pid/environ | sed -e 's/USERNAME=//'` DISP=`grep -z DISPLAY \ /proc/$pid/environ | sed -e 's/DISPLAY=//'` XAUTH=`grep -z XAUTHORITY \ /proc/$pid/environ | sed -e 's/XAUTHORITY=//'` echo $UNAME $DBUS_SESSION_BUS_ADDRESS $DISP $XAUTHORITY # use it DISPLAY=$DISP DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS XAUTHORITY=$XAUTH \ sudo -u $UNAME notify-send -u low -t $timeout "$title" "$text" done -- o__ ,>/'_ o__ (_)\(_),>/'_o__ Yan Seiner (_)\(_) ,>/'_ o__ Personal Trainer (_)\(_),>/'_o__ Professional Engineer (_)\(_) ,>/'_ Who says engineers have to be pencil necked geeks? (_)\(_) As long as nobody gets hurt, a decent explosion livens up any experiment. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
2008/9/9 Jason Kim <[EMAIL PROTECTED]>: > I think the imaginary "xwall" won't work because each user has it's own > X session. > > How possibly a program determine all running X sessions? KDE used to have a demon 'kwrited' that would simply listen for 'wall' messages and then display them to the user. This code probably just needs a bit of cleaning up and would probably work again. Something similar could be done for gnome JohnFlux ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: "Virtual Desktop" - when it'll be back?
On Jul 28, 08 19:41:47 +0200, Zbigniew Baniewski wrote: > Using newest xorg radeon driver (6.9.0), and the newest(?) Xserver as well > (1.4.2), I noticed, that currently it's impossible to use "panned" virtual > desktop (moved with mouse cursor). This is somehow tied to Xrandr-related > things (don't know the details). If radeonhd is working for your card (R500 and up), it has RandR 1.2 compatible panning support (the manpage will show you how). Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Gene Heskett schrieb: > On Tuesday 09 September 2008, Tomasz Chmielewski wrote: >> Gene Heskett schrieb: >>> On Tuesday 09 September 2008, Yan Seiner wrote: How do I go about notifying all users? I am looking for an equivalent of 'wall' for X. xmessage doesn't really work very well as I'd have to mess with xhost in each user's profile. I've looked at libnotify, but it runs into dbus security issues. So how does a sysadmin notify all users of an impending system event (like a shutdown)? >>> What is wrong with just using wall? >> Does "wall" display anything for users running X? No. > > How did you disable that? Here it echo's to every open shell and opens a > message window on windows without open shells on them. Do you really think every Joe and Mary has a shell window opened? -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
I think the imaginary "xwall" won't work because each user has it's own X session. How possibly a program determine all running X sessions? On Tue, 2008-09-09 at 17:45 +0200, Tomasz Chmielewski wrote: > Yan Seiner schrieb: > > On Tue, September 9, 2008 8:34 am, Gene Heskett wrote: > >> On Tuesday 09 September 2008, Yan Seiner wrote: > >>> How do I go about notifying all users? I am looking for an equivalent > >>> of 'wall' for X. xmessage doesn't really work very well as I'd have to > >>> mess > >>> with xhost in each user's profile. > >>> > >>> I've looked at libnotify, but it runs into dbus security issues. > >>> > >>> So how does a sysadmin notify all users of an impending system event > >>> (like a > >>> shutdown)? > >>> > >> What is wrong with just using wall? > > > > Because most of my users will not have a terminal session open. Typically > > they use a browser full-screen, so I need a popup to notify them. > > I guess you need an imaginary "xwall" command. > > -- *** Jason Kim, Software Developer http://userful.com 2nd Floor, 928-6th Ave SW Calgary, AB T2P 0V5 Tel: 403-289-2177 EXT: 210 866-USERFUL (873-7385) Fax: 403-206-7010 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tuesday 09 September 2008, Yan Seiner wrote: >On Tue, September 9, 2008 8:34 am, Gene Heskett wrote: >> On Tuesday 09 September 2008, Yan Seiner wrote: >>>How do I go about notifying all users? I am looking for an equivalent >>>of 'wall' for X. xmessage doesn't really work very well as I'd have to >>> mess >>>with xhost in each user's profile. >>> >>>I've looked at libnotify, but it runs into dbus security issues. >>> >>>So how does a sysadmin notify all users of an impending system event >>> (like a >>>shutdown)? >> >> What is wrong with just using wall? > >Because most of my users will not have a terminal session open. Typically >they use a browser full-screen, so I need a popup to notify them. > >--Yan Well, the pop up was actually a pop under here. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Nice guys don't finish nice. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On 09/09/2008, Yan Seiner <[EMAIL PROTECTED]> wrote: ... > Because most of my users will not have a terminal session open. Typically > they use a browser full-screen, so I need a popup to notify them. Spawn a sub-shell for each user, run "sudo -u $user zenity --warning 'about to reboot'" ... ? (it should work, tested here on F8). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Chuck Robey schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tomasz Chmielewski wrote: >> Gene Heskett schrieb: >>> On Tuesday 09 September 2008, Yan Seiner wrote: How do I go about notifying all users? I am looking for an equivalent of 'wall' for X. xmessage doesn't really work very well as I'd have to mess with xhost in each user's profile. I've looked at libnotify, but it runs into dbus security issues. So how does a sysadmin notify all users of an impending system event (like a shutdown)? >>> What is wrong with just using wall? >> Does "wall" display anything for users running X? No. >> > > Depends if they're running terminals on X ... every terminal, X or not (like > KDE's konsole) will echo whatever you send via wall. > > I don't know what non-programmers susally do, do they usually need (as a > minimum) a login terminal, or not? I would imagine they do, but I am just not > certain about that. Non-technical users tend to ask: "what's this black window" whenever they see a terminal window in their KDE / Gnome session. Those more "techy" non-technical users would say: "I didn't know this *nix still needs MS-DOS to run". -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tue, September 9, 2008 8:45 am, Tomasz Chmielewski wrote: > Yan Seiner schrieb: >> On Tue, September 9, 2008 8:34 am, Gene Heskett wrote: >>> On Tuesday 09 September 2008, Yan Seiner wrote: How do I go about notifying all users? I am looking for an equivalent of 'wall' for X. xmessage doesn't really work very well as I'd have to mess with xhost in each user's profile. I've looked at libnotify, but it runs into dbus security issues. So how does a sysadmin notify all users of an impending system event (like a shutdown)? >>> What is wrong with just using wall? >> >> Because most of my users will not have a terminal session open. >> Typically >> they use a browser full-screen, so I need a popup to notify them. > > I guess you need an imaginary "xwall" command. :-) Bingo. That's what I am looking for. I've found some ugly hacks using libnotify, dbus, and proc that should work under gnome and xfce. I'll see if I can hack up that xwall command. --Yan -- o__ ,>/'_ o__ (_)\(_),>/'_o__ Yan Seiner (_)\(_) ,>/'_ o__ Personal Trainer (_)\(_),>/'_o__ Professional Engineer (_)\(_) ,>/'_ Who says engineers have to be pencil necked geeks? (_)\(_) As long as nobody gets hurt, a decent explosion livens up any experiment. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: > I think it'd be good if the authentication stuff could be made/kept > optional or at least not DRM specific. (I'm not sure GEM or the DRM in > general is within scope of this spec at all) I have to admit that I'm not very excited by the existing authentication protocol. What we want is a way to let applications identify themselves with the kernel and 'prove' that they have permission to access kernel objects. It seems like having the X server return a 'cookie' that the client could use with the kernel module might make things simpler: ┌─── DRI2Connect window: WINDOW type: STRING ▶ driver: STRING device: STRING -- device file name auth-data: LISTofCARD8 └─── 'auth-data' is an arbitrary array of bytes which the client passes to the direct rendering system to validate the client's access of direct rendering objects created by the X server. It seems like this offers precisely the right guarantee -- the client proves to the kernel that it is connected to the X server and thus should be granted permission to access the X server objects. Under some tighter access control mechanisms, the 'auth-data' could even be generated per-client so that the client would only have access to a sub-set of X server objects. > I do wonder if DRI2GetBuffers should return the drawable position > relative to the origin of each buffer... guess it isn't strictly > necessary except maybe for the real frontbuffer. One of the requirements in DRI2 is that the 'real' front buffer be invisible to applications; there's no way the application can sensibly use those contents. Moreover, the drawable position may change without any warning due to window configuration. > For DRI2CopyRegion, you're leaving it to the DDX driver to pick the CRTC > to synchronize to? I'm not sure that'll work too well with overlapping > viewports, where the user may want to choose which CRTC to synchronize > to for each application. Yeah, I don't see a good way to avoid this, and the client can always pass in 'Automatic' (0) and let the server pick the 'right' one. > This request also still seems to be missing > return values for the sequence number when the copy is expected to take > place and tokens for synchronization of direct rendering to the > source/destination buffer. Eliminating the reply avoids a round trip, so I'm in favor of not providing any if it's not strictly necessary. I don't know if the GL api requires us to provide the expected sequence number back to the application. For synchronization, we should expect the kernel module to perform this automatically -- once the X server has processed this request, the kernel can pend further rendering to the source buffer until the copy has finished. That would, of course, require that the application know that the kernel has received the copy command from the X server -- so the client would need to get something from X server indicating that it had finished processing the Copy request. The easiest thing to use would be a reply, but we'd structure the library so that the client wouldn't pend on the reply and could block just before touching the back buffer again. Note that there isn't any synchronization on the real front buffer; that isn't a legal target for direct rendering. > Oh, and I think it should take relative > sequence numbers as well as absolute ones. Yeah, GL does kinda require this. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Yan Seiner schrieb: > On Tue, September 9, 2008 8:34 am, Gene Heskett wrote: >> On Tuesday 09 September 2008, Yan Seiner wrote: >>> How do I go about notifying all users? I am looking for an equivalent >>> of 'wall' for X. xmessage doesn't really work very well as I'd have to >>> mess >>> with xhost in each user's profile. >>> >>> I've looked at libnotify, but it runs into dbus security issues. >>> >>> So how does a sysadmin notify all users of an impending system event >>> (like a >>> shutdown)? >>> >> What is wrong with just using wall? > > Because most of my users will not have a terminal session open. Typically > they use a browser full-screen, so I need a popup to notify them. I guess you need an imaginary "xwall" command. -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomasz Chmielewski wrote: > Gene Heskett schrieb: >> On Tuesday 09 September 2008, Yan Seiner wrote: >>> How do I go about notifying all users? I am looking for an equivalent >>> of 'wall' for X. xmessage doesn't really work very well as I'd have to mess >>> with xhost in each user's profile. >>> >>> I've looked at libnotify, but it runs into dbus security issues. >>> >>> So how does a sysadmin notify all users of an impending system event (like a >>> shutdown)? >>> >> What is wrong with just using wall? > > Does "wall" display anything for users running X? No. > Depends if they're running terminals on X ... every terminal, X or not (like KDE's konsole) will echo whatever you send via wall. I don't know what non-programmers susally do, do they usually need (as a minimum) a login terminal, or not? I would imagine they do, but I am just not certain about that. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjGmaIACgkQz62J6PPcoOkBtgCgiCMPsjUqBU/4vXDjKotgB8jb HpEAoJfn5gdc3r2aNwrYRZ35iKYfTbif =5zWa -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tue, September 9, 2008 8:34 am, Gene Heskett wrote: > On Tuesday 09 September 2008, Yan Seiner wrote: >>How do I go about notifying all users? I am looking for an equivalent >>of 'wall' for X. xmessage doesn't really work very well as I'd have to >> mess >>with xhost in each user's profile. >> >>I've looked at libnotify, but it runs into dbus security issues. >> >>So how does a sysadmin notify all users of an impending system event >> (like a >>shutdown)? >> > What is wrong with just using wall? Because most of my users will not have a terminal session open. Typically they use a browser full-screen, so I need a popup to notify them. --Yan -- o__ ,>/'_ o__ (_)\(_),>/'_o__ Yan Seiner (_)\(_) ,>/'_ o__ Personal Trainer (_)\(_),>/'_o__ Professional Engineer (_)\(_) ,>/'_ Who says engineers have to be pencil necked geeks? (_)\(_) As long as nobody gets hurt, a decent explosion livens up any experiment. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Gene Heskett schrieb: > On Tuesday 09 September 2008, Yan Seiner wrote: >> How do I go about notifying all users? I am looking for an equivalent >> of 'wall' for X. xmessage doesn't really work very well as I'd have to mess >> with xhost in each user's profile. >> >> I've looked at libnotify, but it runs into dbus security issues. >> >> So how does a sysadmin notify all users of an impending system event (like a >> shutdown)? >> > What is wrong with just using wall? Does "wall" display anything for users running X? No. -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
On Tuesday 09 September 2008, Yan Seiner wrote: >How do I go about notifying all users? I am looking for an equivalent >of 'wall' for X. xmessage doesn't really work very well as I'd have to mess >with xhost in each user's profile. > >I've looked at libnotify, but it runs into dbus security issues. > >So how does a sysadmin notify all users of an impending system event (like a >shutdown)? > What is wrong with just using wall? >--Yan >___ >xorg mailing list >xorg@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xorg -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If at first you don't succeed, work for Microsoft. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Daniel Stone wrote: > On Tue, Sep 09, 2008 at 03:24:38PM +0100, Steven J Newbury wrote: >> I the biggest thing needed currently from an Xorg perspective, with >> respect to multiseat, would be the ability to have a HAL policy tie >> specific devices to specific displays - unless I'm missing something? > > This is probably ConsoleKit, really. I would have thought so yeah. It would be nice if you could also tie a display to a sound device. If console kit took care of this and defined a "seat" in such a way then sound should also "just work" with pulseaudio which already has good integration with console kit. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Notify all users
Yan Seiner wrote: > How do I go about notifying all users? I am looking for an equivalent > of 'wall' for X. xmessage doesn't really work very well as I'd have to mess > with xhost in each user's profile. > > I've looked at libnotify, but it runs into dbus security issues. > > So how does a sysadmin notify all users of an impending system event (like a > shutdown)? I think you are probably on roughly the right lines with libnotify, but not the library itself, more the specification. I guess some sort of event from hal or similar should be exposed to all users via dbus and some sort of process (e.g. the notification notification daemon that displays messages conforming to the FDO notification spec - the kind libnotify generates) will be responsible for displaying said message to each user. I'm not very clued up with dbus to know much about how the system and session buses interact etc. but I think this is the right general approach. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
On Tue, 2008-09-09 at 07:38 -0700, Yan Seiner wrote: > On Tuesday 09 September 2008 07:24:38 am Steven J Newbury wrote: > > > > > I the biggest thing needed currently from an Xorg perspective, with > > respect to multiseat, would be the ability to have a HAL policy tie > > specific devices to specific displays - unless I'm missing something? > > Multiseat is available, at least in beta. > > http://wiki.c3sl.ufpr.br/multiseat/index.php/Main_Page > > I've been running multiseat based on nvidia binary drivers for quite a while. > > It's an unsupported configuration but it works quite well. I'll try to get > some time and document what I've done. > > It's not hard. I do some udev magic to ID the keyboard and then it's a piece > of cake. > > Section "ServerLayout" > Identifier "Noriko" > Screen 0 "Noriko" 0 0 > InputDevice"MouseNoriko" "CorePointer" > InputDevice"KeyboardNoriko" "CoreKeyboard" > Option "SingleCard" "yes" > Option "AIGLX" "true" > Option "AutoAddDevices" "no" > Option "xinerama" "false" > EndSection > > Section "InputDevice" > Identifier "KeyboardNoriko" > Driver "evdev" > Option "device" "/dev/input/by-user/KeyboardNoriko" > Option "CoreKeyboard" > EndSection > > Section "InputDevice" > Identifier "MouseNoriko" > Driver "mouse" > Option "Protocol" "auto" > > Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:4.1:1.0-mouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "Monitor" > Identifier "Noriko" > VendorName "VSC" > ModelName "E40-3" > Option "DPMS" > EndSection > > Section "Device" > Identifier "Noriko" > Driver "nvidia" > VendorName "nVidia Corporation" > BoardName "Quadra" > Option "ProbeAllGpus" "false" > Option "Noint10" "true" > Option "Twinview" "false" > Option "MultiGPU" "off" > Option "SLI" "off" > Option "NvAGP" "3" > BusID "PCI:6:0:0" > EndSection > > > This should get you started. Actually, I already have a multiseat setup! :) It would be nice to have working input hotplug though, with the ability to tie specific devices to a specific seat. I'll take a look at ConsoleKit.. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-synaptics 0.15.1
Wow, great job guys! Works perfectly on an HP laptop "HP Pavilion dv6000". With the previous driver tapping would not work at all. Thanks, Michael On Sun, Sep 7, 2008 at 4:52 AM, Christoph Brill <[EMAIL PROTECTED]> wrote: > Adel Gadllah (1): > Re-enable TapButtons and CornerButtons to work by default. > > Christian Schmitt (1): > Add support for Apple touchpads to the fdi file > > Christoph Brill (6): > Add .fdi file from gentoo (also used by pld) > Fix "make distcheck" > Use config.h if available > Update man page to contain a paragraph about fdi files > Add a note on how to pass options to the driver using the fdi file > Bump to 0.15.1 > > Fedor P. Goncharov (1): > Add autodetection of right scroll wheel region with very large X > coordinate > > Henrik Rydberg (4): > Add bcm5974 to fdi/11-x11-synaptics.fdi > Fix the "No such device" problem when reloading a driver > Disentangle two-finger tap and two-finger scrolling > Tighter default for MaxTapMove > > Matthieu Herrb (2): > Fix build if we don't enable BUILD_EVENTCOMM. > syndaemon: fix BSD-specific build issues (signal related) > > Mattia Dongili (1): > Add 02-scandir-dev-input.patch from Debian > > Peter Hutterer (6): > Move synaptics.h into include/, create synapticsstr.h for private > structs. > Shut up compiler warning, HandleClickWithFingers should be a void. > Fill up version info correctly. > Add support for device properties. > Compile fixes. > Fix build with non-property enabled servers. > > William Grant (1): > Fix two off-by-one errors in the property handling code > > git tag: xf86-input-synaptics-0.15.1 > > http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-0.15.1.tar.bz2 > MD5: 0a588c729295b9a91a05d9d157270917 xf86-input-synaptics-0.15.1.tar.bz2 > SHA1: 74a986265570e0a25eb1e9a880a04653d48d7bd1 > xf86-input-synaptics-0.15.1.tar.bz2 > > http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-0.15.1.tar.gz > MD5: 7ec9ad9a4ffac2d808387b0e653d6cb8 xf86-input-synaptics-0.15.1.tar.gz > SHA1: efb839a957f2ee1dd1da996cde2980756c4d4139 > xf86-input-synaptics-0.15.1.tar.gz > > > > ___ > xorg-announce mailing list > [EMAIL PROTECTED] > http://lists.freedesktop.org/mailman/listinfo/xorg-announce > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
On Tuesday 09 September 2008 07:24:38 am Steven J Newbury wrote: > > I the biggest thing needed currently from an Xorg perspective, with > respect to multiseat, would be the ability to have a HAL policy tie > specific devices to specific displays - unless I'm missing something? Multiseat is available, at least in beta. http://wiki.c3sl.ufpr.br/multiseat/index.php/Main_Page I've been running multiseat based on nvidia binary drivers for quite a while. It's an unsupported configuration but it works quite well. I'll try to get some time and document what I've done. It's not hard. I do some udev magic to ID the keyboard and then it's a piece of cake. Section "ServerLayout" Identifier "Noriko" Screen 0 "Noriko" 0 0 InputDevice"MouseNoriko" "CorePointer" InputDevice"KeyboardNoriko" "CoreKeyboard" Option "SingleCard" "yes" Option "AIGLX" "true" Option "AutoAddDevices" "no" Option "xinerama" "false" EndSection Section "InputDevice" Identifier "KeyboardNoriko" Driver "evdev" Option "device" "/dev/input/by-user/KeyboardNoriko" Option "CoreKeyboard" EndSection Section "InputDevice" Identifier "MouseNoriko" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/by-path/pci-:00:02.1-usb-0:4.1:1.0-mouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Noriko" VendorName "VSC" ModelName "E40-3" Option "DPMS" EndSection Section "Device" Identifier "Noriko" Driver "nvidia" VendorName "nVidia Corporation" BoardName "Quadra" Option "ProbeAllGpus" "false" Option "Noint10" "true" Option "Twinview" "false" Option "MultiGPU" "off" Option "SLI" "off" Option "NvAGP" "3" BusID "PCI:6:0:0" EndSection This should get you started. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Mach64: Check pScreenInfo->driverName in ATIMach64XVInitialiseAdaptor
On Mon, 2008-09-08 at 19:05 -0700, Aaron Plattner wrote: > This patch fixes a bug that causes problems when non-mach64 screens are > present. ATIMach64XVInitialiseAdaptor gets called by any driver that calls > xf86XVListGenericAdaptors, and it happily does this: > > > > As you can imagine, this doesn't always work out so well. Applied, thanks. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
On Tue, Sep 09, 2008 at 03:24:38PM +0100, Steven J Newbury wrote: > I the biggest thing needed currently from an Xorg perspective, with > respect to multiseat, would be the ability to have a HAL policy tie > specific devices to specific displays - unless I'm missing something? This is probably ConsoleKit, really. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
On Tue, 2008-09-09 at 15:07 +0100, Simos Xenitellis wrote: > I would say it is more of an issue that many tasks based on > open-source software can be achieved, it just requires the person(s) > to lead the effort. > Apart from the core functionality/programming that takes place in > Xorg, it's an issue of packaging and making it easy for the users to > install and use. > > Looking at http://brainstorm.ubuntu.com/ it shows that Multiseat has a page at > http://brainstorm.ubuntu.com/idea/3442/ > with over 300 'votes'. Top issues have over 5000 such votes. > > It looks to be a trend; there is amazing core functionality in X.Org, > which requires packaging and dissemination to the end-users. This > does mean that the developers have even more tasks to do; other people > should lead the effort to bring this functionality to the end-users. > > Simos > > On Tue, Sep 9, 2008 at 2:10 PM, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: > > Simos Xenitellis schrieb: > >> > >> Do a search for "multiseat". I think it shows more results. > >> I have not tried this, so it's good to post a summary on the list once > >> you have some results. > > > > It still wonders a bit why i.e. Linux distributors still don't offer an easy > > to use tool for setting up a multiseat workstation. > > It's a clear advantage over Windows, where setting up a multiseat is just > > impossible because of design. Use it in self-service Kiosks, libraries, > > schools etc. > > > > > > I once saw a commercial multiseat Kiosk distribution running Linux[1], where > > they had this feature made perfectly. > > > > First, you equip your workstation in multiple graphic cards, keyboards etc. > > (obvious step). > > > > When the distribution boots, it automatically configures all graphic cards. > > Because there can be many keyboards and monitors, it can confuse the user > > which device belongs where, and therefore, on each monitor, it displays > > something like: > > > > "Press F4 and left-click your mouse if you're > > sitting in front of this workstation". > > > > or > > > > "Press F2 and lefte-click your mouse if you're > > sitting in front of this workstation". > > > > > > This way, it knows that a given keyboard is attached to a given monitor. > > > > Smart! > > > > > > > > [1] http://www2.userful.com/products/userful-multiplier/how-its-done, > > available as a free download I the biggest thing needed currently from an Xorg perspective, with respect to multiseat, would be the ability to have a HAL policy tie specific devices to specific displays - unless I'm missing something? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Notify all users
How do I go about notifying all users? I am looking for an equivalent of 'wall' for X. xmessage doesn't really work very well as I'd have to mess with xhost in each user's profile. I've looked at libnotify, but it runs into dbus security issues. So how does a sysadmin notify all users of an impending system event (like a shutdown)? --Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
I would say it is more of an issue that many tasks based on open-source software can be achieved, it just requires the person(s) to lead the effort. Apart from the core functionality/programming that takes place in Xorg, it's an issue of packaging and making it easy for the users to install and use. Looking at http://brainstorm.ubuntu.com/ it shows that Multiseat has a page at http://brainstorm.ubuntu.com/idea/3442/ with over 300 'votes'. Top issues have over 5000 such votes. It looks to be a trend; there is amazing core functionality in X.Org, which requires packaging and dissemination to the end-users. This does mean that the developers have even more tasks to do; other people should lead the effort to bring this functionality to the end-users. Simos On Tue, Sep 9, 2008 at 2:10 PM, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: > Simos Xenitellis schrieb: >> >> Do a search for "multiseat". I think it shows more results. >> I have not tried this, so it's good to post a summary on the list once >> you have some results. > > It still wonders a bit why i.e. Linux distributors still don't offer an easy > to use tool for setting up a multiseat workstation. > It's a clear advantage over Windows, where setting up a multiseat is just > impossible because of design. Use it in self-service Kiosks, libraries, > schools etc. > > > I once saw a commercial multiseat Kiosk distribution running Linux[1], where > they had this feature made perfectly. > > First, you equip your workstation in multiple graphic cards, keyboards etc. > (obvious step). > > When the distribution boots, it automatically configures all graphic cards. > Because there can be many keyboards and monitors, it can confuse the user > which device belongs where, and therefore, on each monitor, it displays > something like: > > "Press F4 and left-click your mouse if you're > sitting in front of this workstation". > > or > > "Press F2 and lefte-click your mouse if you're > sitting in front of this workstation". > > > This way, it knows that a given keyboard is attached to a given monitor. > > Smart! > > > > [1] http://www2.userful.com/products/userful-multiplier/how-its-done, > available as a free download > > > -- > Tomasz Chmielewski > http://wpkg.org > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XTest and multiple pointers
> > we're currently trying to control multiple X pointers through XTest.
> > Moving them using XTestFakeDeviceMotionEvent works as expected; however,
> > sending a button event using XTestFakeDeviceButtonEvent doesn't.
> > In fact, the test program from [1] segfaults in XNextEvent
> > (xorg/lib/libX11/src/NextEvent.c, line 51). qelt (and therefore
> > dpy->head) doesn't point anywhere sensible, so is this perhaps an
> > internal bug?
> This is usually caused by the event being passed in not being the right size.
> Xlib is picky about the size of events, so you must make sure you always pass
> in an XEvent struct (96 bytes), even if what you actually use is a
> XDeviceMotionEvent (or whatever).
> Could this be the cause of your issue?
As mentioned, we were using your test program.. and that does pass an
XEvent struct. The segfault happens here:
int
XNextEvent (
register Display *dpy,
register XEvent *event)
{
register _XQEvent *qelt;
LockDisplay(dpy);
if (dpy->head == NULL)
_XReadEvents(dpy);
qelt = dpy->head;
*event = qelt->event; // <- CRASH
_XDeq(dpy, NULL, qelt);
UnlockDisplay(dpy);
return 0;
}
qelt is an invalid pointer, meaning dpy->head is invalid, too. I can't
imagine that this happens from userspace..
Thanks again, Yours, Florian
--
0666 - Filemode of the Beast
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Device Properties Protocol Spec - Draft 1
On Mon, Sep 08, 2008 at 11:19:21AM +0200, Simon Thum wrote: > Peter Hutterer wrote: >> The difference to the current implementation is that there is no >> meta-information about the property. This information included immutable, >> client-created, range and pending. I deem all four as too much information. >> >> If such information is required in the future, such requests can be added >> easily in future versions of XInput. > I guess you are just not exposing those? > My concern is that a client could remove properties installed by the > server or a driver. > > In the readonly case, I think it should be possible to tell a property > which refuses to be set due to the value apart from a property which > generally is 'read-only', i.e. has a always-fail setter or some > unexposed flag. Could be BadValue vs. BadMatch, but I'm missing it in > the ChangeDeviceProperty spec (readonly is arguably a type mismatch). we could do that as BadAccess, though I'm not sure how that'd mingle with the security stuff. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Simos Xenitellis schrieb: > Do a search for "multiseat". I think it shows more results. > I have not tried this, so it's good to post a summary on the list once > you have some results. It still wonders a bit why i.e. Linux distributors still don't offer an easy to use tool for setting up a multiseat workstation. It's a clear advantage over Windows, where setting up a multiseat is just impossible because of design. Use it in self-service Kiosks, libraries, schools etc. I once saw a commercial multiseat Kiosk distribution running Linux[1], where they had this feature made perfectly. First, you equip your workstation in multiple graphic cards, keyboards etc. (obvious step). When the distribution boots, it automatically configures all graphic cards. Because there can be many keyboards and monitors, it can confuse the user which device belongs where, and therefore, on each monitor, it displays something like: "Press F4 and left-click your mouse if you're sitting in front of this workstation". or "Press F2 and lefte-click your mouse if you're sitting in front of this workstation". This way, it knows that a given keyboard is attached to a given monitor. Smart! [1] http://www2.userful.com/products/userful-multiplier/how-its-done, available as a free download -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XTest and multiple pointers
On Tue, Sep 09, 2008 at 11:24:48AM +0200, Florian Echtler wrote: > we're currently trying to control multiple X pointers through XTest. > Moving them using XTestFakeDeviceMotionEvent works as expected; however, > sending a button event using XTestFakeDeviceButtonEvent doesn't. > > In fact, the test program from [1] segfaults in XNextEvent > (xorg/lib/libX11/src/NextEvent.c, line 51). qelt (and therefore > dpy->head) doesn't point anywhere sensible, so is this perhaps an > internal bug? This is usually caused by the event being passed in not being the right size. Xlib is picky about the size of events, so you must make sure you always pass in an XEvent struct (96 bytes), even if what you actually use is a XDeviceMotionEvent (or whatever). Could this be the cause of your issue? I can only test this on my other box next week, not before then. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem with Xdialog/Firefox and different Xorg versions
Hi, On Tue, Sep 09, 2008 at 10:50:51AM +0100, George Wright wrote: > Everything just works fine on most modern platforms, but trying to run the > thinclient server on Fedora Core 6 results in Xdialog not showing fonts at > all. Trying to launch Xdialog manually inside Xvnc results in a very > unhelpful error message "Floating point exception". The default is to use builtin fonts only; --disable-builtin-fonts for the server, I think, if you want to use core fonts. > On a possibly unrelated note, Firefox also has trouble executing on FC6 > inside > my Xvnc server. Trying to run firefox-bin directly results in: > > The program 'Gecko' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadName (named color or font does not exist)'. > (Details: serial 569 error_code 15 request_code 45 minor_code 0) ^^ > (Note to programmers: normally, X errors are reported asynchronously; >that is, you will receive the error a while after causing it. >To debug your program, run it with the --sync command line >option to change this behavior. You can then get a meaningful >backtrace from your debugger if you break on the gdk_x_error() function.) > > Again, this firefox-bin works fine if launched in the shipped X server. > Strangely enough, it also works fine if launched via strace inside Xvnc. #define X_OpenFont 45 So, same thing. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ubuntu 8.04.1 rotate screen 90 degrees
Could you look inside /var/log/Xorg.0.log please and see if you have something like (==) intel(0): Using EXA for acceleration or similar. i'm wondering if you're using EXA or XAA 2008/9/9 James Den Kaat <[EMAIL PROTECTED]>: > I have installed Ubuntu 8.04.1 on an atom motherboard with an Intel > 945gm graphics on board. I have installed the latest intel drivers and > al is fine in normal mode. However, I have a requirement to run the > screen in portrait mode, that is at 90 degrees, when I do this > everything slows down to a crawl. > > Is there any way to improve performance so that it gives a similar > result no matter how I rotate the screen? > > Thank You > > J DenKaat > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Mon, 2008-09-08 at 17:58 -0400, Kristian Høgsberg wrote: > Hi, > > Keith talked me intro writing a spec for DRI2, which I grudgingly must > admit is a good idea. I used the randr spec as a template, except I > replaced the flowery section dividers with a more fitting gears motif. > It's still a work in progress, mostly the introductory/background > sections though. The requests and wire encoding sections are mostly > complete and is close to what's in the git repos at this point. The > implementation isn't fully uptodate with the spec yet, but I figured > it would be wise to circulate the spec before doing more code churn, > so here it is. I think it'd be good if the authentication stuff could be made/kept optional or at least not DRM specific. (I'm not sure GEM or the DRM in general is within scope of this spec at all) I do wonder if DRI2GetBuffers should return the drawable position relative to the origin of each buffer... guess it isn't strictly necessary except maybe for the real frontbuffer. For DRI2CopyRegion, you're leaving it to the DDX driver to pick the CRTC to synchronize to? I'm not sure that'll work too well with overlapping viewports, where the user may want to choose which CRTC to synchronize to for each application. This request also still seems to be missing return values for the sequence number when the copy is expected to take place and tokens for synchronization of direct rendering to the source/destination buffer. Oh, and I think it should take relative sequence numbers as well as absolute ones. Should 10.2 say DRI2_BUFFER_BACK_LEFT rather than DRI2_BUFFER_FRONT_LEFT? P.S. Does the author of http://dri.freedesktop.org/wiki/DirectRenderingToRedirectedWindows deserve an acknowledgement as well? ;) -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Problem with Xdialog/Firefox and different Xorg versions
Hello all, I have a rather strange problem that's been bothering me for a while. Basically, I'm working on the TightVNC 1.5-xserver branch, which has Xvnc rebased to Xorg 7.4RC rather than 6.x, and everything seems just fine. As part of the thinclient "package", we're using Xdialog extensively for choosing sessions etc. The whole build process is done on a very old buildserver (Red Hat 7.3, with upgraded gcc and autotools and a few other things) and the Xorg 7.4 dependencies for compiling the xorg-xserver are done on the spot just prior to compiling xorg-xserver (and thus Xvnc). Everything just works fine on most modern platforms, but trying to run the thinclient server on Fedora Core 6 results in Xdialog not showing fonts at all. Trying to launch Xdialog manually inside Xvnc results in a very unhelpful error message "Floating point exception". The Xdialog binary works fine though if I run it on the shipped X server that came with FC6, and it also works fine on more modern distros in the Xvnc server I have (Ubuntu 8.04 and Fedora 9 are both working as expected). It also works fine if I statically link Xdialog to the X11 libraries and run it inside Xvnc on FC6, but this is not a preferred solution. On a possibly unrelated note, Firefox also has trouble executing on FC6 inside my Xvnc server. Trying to run firefox-bin directly results in: The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadName (named color or font does not exist)'. (Details: serial 569 error_code 15 request_code 45 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Again, this firefox-bin works fine if launched in the shipped X server. Strangely enough, it also works fine if launched via strace inside Xvnc. Any suggestions or pointers in the right direction would be much appreciated! Regards, George -- George Wright, http://www.gwright.org.uk signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XTest and multiple pointers
Hello everybody, we're currently trying to control multiple X pointers through XTest. Moving them using XTestFakeDeviceMotionEvent works as expected; however, sending a button event using XTestFakeDeviceButtonEvent doesn't. In fact, the test program from [1] segfaults in XNextEvent (xorg/lib/libX11/src/NextEvent.c, line 51). qelt (and therefore dpy->head) doesn't point anywhere sensible, so is this perhaps an internal bug? Or can anybody give us a hint on what other methods to control the extension pointers from an userspace program exist? [1] http://wearables.unisa.edu.au/mpx/?q=xi2_sample Many thanks, Yours, Florian -- 0666 - Filemode of the Beast ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
