Re: Keystroke flow in X.org
On Fri, Jun 12, 2009 at 02:36:44PM +1000, Timothy S. Nelson wrote: Here's a rather mundane article with a good diagram that I just wrote. It should probably be linked to from http://www.x.org/wiki/XKB but since I don' tappear to have access to do that, I'm posting the link on the mailing list instead. http://computerstuff.jdarx.info/content/keystroke-flow-xorg Also, if people with some clues about xkb could review it, that would be great. First - I appreciate that you wrote up some documentation and that you're putting it online. However, in this case I'm really sorry to say this is seriously wrong (and also a bit confusing). Here's a few quick points: - drivers don't have anything to do with XKB anymore (in git anyway). XKB is purely handled in the server now. - the files in xkb/* are only read by xkbcomp to compile the original description, key events don't go that path at all - the client still receives keycodes andn not keysyms, the KC-KS translation is done in the client after retreiving the keymap table (which is usually done before the events arrive anyway). - scancodes == keycodes - what you (I think) refer to are symbolic names for some keys used in the xkb description files. they have nothing to do with anything other than help mapping during the key table creation Those are just the points I can find in a quick 3 minute read. Please take this offline, I shudder at the thought of the collatoral damage of digg, reddit or slashdot picking this up. In years from now we'll still have to correct people that that's now how it works at all. Sorry. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
On Fri, Jun 12, 2009 at 12:20:16AM -0400, Matt Hayes wrote: Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy. Well, after the latest updates to Slackware and Xorg, what I'm seeing now is the side buttons on my Microsoft Intellimouse Explorer 3 are mapping the buttons (side buttons) as 8 9 instead of 6 7. However, making a change in xorg.conf to facilitate the change in mapping, things DO work fine in X, but not other applications such as Enemy Territory. if HAL takes effect, xorg.conf sections are generally ignored these days. So chances are it's not even picking up what you have configured. the other chance is of course that your DE is overwriting it on login. Now, what I don't understand is why hal is detecting the mouse as Num_buttons 32... I even created a hal policy to map the buttons how I normally would in xorg.conf and this had no effect. HAL is not detecting anything. Think of hal being the equivalent to the Option Device /dev/input/event1 line. That's really all it does. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, 12 Jun 2009, Peter Hutterer wrote: On Fri, Jun 12, 2009 at 02:36:44PM +1000, Timothy S. Nelson wrote: Here's a rather mundane article with a good diagram that I just wrote. It should probably be linked to from http://www.x.org/wiki/XKB but since I don' tappear to have access to do that, I'm posting the link on the mailing list instead. http://computerstuff.jdarx.info/content/keystroke-flow-xorg Also, if people with some clues about xkb could review it, that would be great. First - I appreciate that you wrote up some documentation and that you're putting it online. However, in this case I'm really sorry to say this is seriously wrong (and also a bit confusing). Yay clueful people! :). I'm reordering your post so that my replies make sense. Those are just the points I can find in a quick 3 minute read. Please take this offline, I shudder at the thought of the collatoral damage of digg, reddit or slashdot picking this up. In years from now we'll still have to correct people that that's now how it works at all. I agree that (after reading what you said) it needs correction. However, I hope to have a corrected version on-line after I've gotten some further clarification. - the files in xkb/* are only read by xkbcomp to compile the original description, key events don't go that path at all Ok, I think this can be incorporated into the diagram with no problems. Here's a few quick points: - drivers don't have anything to do with XKB anymore (in git anyway). XKB is purely handled in the server now. - the client still receives keycodes andn not keysyms, the KC-KS translation is done in the client after retreiving the keymap table (which is usually done before the events arrive anyway). - scancodes == keycodes - what you (I think) refer to are symbolic names for some keys used in the xkb description files. they have nothing to do with anything other than help mapping during the key table creation So, here's my impression of how it works based on what you've just said. - When a keystroke comes from the hardware, it gets picked up and translated by the xmodmap map from a key/scan code into a symbol. - The translation table is generated from xkb/*. - The compose/locale stuff happens after the xmodmap translation table. Am I at all right? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to run the X xserver in a chroot environment
Hi, for the records: stopping HAL outside the chroot and starting it inside the chroot works, and now I can use X inside a chroot. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, 12 Jun 2009, Timothy S. Nelson wrote: So, here's my impression of how it works based on what you've just said. [snip] Yuck. Let me do some more reworking. - When a keystroke comes from the hardware, it gets picked up and sent to the client (ie. application/program). - The application program (calling on ???) translates it into a character using the following process: - Translates from a key/scan code into a symbol using the xmodmap map - The translation table is generated from xkb/*. - The compose/locale stuff happens after the xmodmap translation table. Is that better? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[synaptics] [PATCH] Fix typo. s/tough/though/
Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net --- man/synaptics.man |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/synaptics.man b/man/synaptics.man index d990304..8f7812c 100644 --- a/man/synaptics.man +++ b/man/synaptics.man @@ -16,7 +16,7 @@ synaptics \- Synaptics touchpad input driver .SH DESCRIPTION .B synaptics is an __xservername__ input driver for the touchpads from Synaptics -Incorporated. Even tough these touchpads (by default, operating in a +Incorporated. Even though these touchpads (by default, operating in a compatibility mode emulating a standard mouse) can be handled by the normal evdev or mouse drivers, this driver allows more advanced features of the touchpad to become available. Some benefits would be: -- 1.6.3.1 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, 12 Jun 2009, Peter Hutterer wrote: - scancodes == keycodes Well, might not be exactly true, depending on what kind of scancodes you are talking about. For example, the F1 key, according to the Microsoft Keyboard Scan Code Specification, is listed as key 112, with a scan 1 make value of 59. This value is also used, for example, over the RDP protocol. But in a X11 context, say when viewing the keycode using xev, the keycode is 67, ie keycode is scancode plus 8. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, Jun 12, 2009 at 10:41:59AM +0200, Peter Åstrand wrote: On Fri, 12 Jun 2009, Peter Hutterer wrote: - scancodes == keycodes Well, might not be exactly true, depending on what kind of scancodes you are talking about. For example, the F1 key, according to the Microsoft Keyboard Scan Code Specification, is listed as key 112, with a scan 1 make value of 59. This value is also used, for example, over the RDP protocol. But in a X11 context, say when viewing the keycode using xev, the keycode is 67, ie keycode is scancode plus 8. yeah, sorry. I forgot about that. Due to some core protocol limitation the X keycode is 'actual keycode + 8'. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, Jun 12, 2009 at 05:21:53PM +1000, Timothy S. Nelson wrote: On Fri, 12 Jun 2009, Timothy S. Nelson wrote: So, here's my impression of how it works based on what you've just said. [snip] Yuck. Let me do some more reworking. - When a keystroke comes from the hardware, it gets picked up and sent to the client (ie. application/program). - The application program (calling on ???) translates it into a character using the following process: - Translates from a key/scan code into a symbol using the xmodmap map - The translation table is generated from xkb/*. - The compose/locale stuff happens after the xmodmap translation table. Is that better? yeah, close enough, except that in most cases xmodmap has little influence on anything. I can't remember the last time I used it when it wasn't to debug some weird setup from a bugreport. it's something like: 1. server starts up, compiles XKB map for each keyboard device based on xkeyboard-config's files using xkbcomp. 2. clients query server for the XKB map and store it or use it to spread love and/or happiness. 3. key event comes in, driver adds 8 because, hey, why not. also, bonghits. 4. (scancode + 8) passes through the XKB layer. if it's not assigned to any action (e.g. Terminate_Server) it's just passed through and sent to the client. 5. client gets keycode, uses previously obtained XKB map to look up keysym. then does something to render it (I really don't know this part). if the physical keyboard changes, the server sends out a keymap notify event and the cycle starts at 2 again. Hopefully, anyway, otherwise the amount of happiness is significantly less than hoped for (up key printscreen misc snafu). also, friday. beer. mhmmm. beer. *drool*. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [synaptics] [PATCH] Fix typo. s/tough/though/
On Fri, Jun 12, 2009 at 09:53:58AM +0200, Paul Menzel wrote: Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net --- man/synaptics.man |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/synaptics.man b/man/synaptics.man index d990304..8f7812c 100644 --- a/man/synaptics.man +++ b/man/synaptics.man @@ -16,7 +16,7 @@ synaptics \- Synaptics touchpad input driver .SH DESCRIPTION .B synaptics is an __xservername__ input driver for the touchpads from Synaptics -Incorporated. Even tough these touchpads (by default, operating in a +Incorporated. Even though these touchpads (by default, operating in a compatibility mode emulating a standard mouse) can be handled by the normal evdev or mouse drivers, this driver allows more advanced features of the touchpad to become available. Some benefits would be: -- 1.6.3.1 thanks for the patch, pushed. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. -Matt Peter Hutterer wrote: On Fri, Jun 12, 2009 at 12:20:16AM -0400, Matt Hayes wrote: Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy. Well, after the latest updates to Slackware and Xorg, what I'm seeing now is the side buttons on my Microsoft Intellimouse Explorer 3 are mapping the buttons (side buttons) as 8 9 instead of 6 7. However, making a change in xorg.conf to facilitate the change in mapping, things DO work fine in X, but not other applications such as Enemy Territory. if HAL takes effect, xorg.conf sections are generally ignored these days. So chances are it's not even picking up what you have configured. the other chance is of course that your DE is overwriting it on login. Now, what I don't understand is why hal is detecting the mouse as Num_buttons 32... I even created a hal policy to map the buttons how I normally would in xorg.conf and this had no effect. HAL is not detecting anything. Think of hal being the equivalent to the Option Device /dev/input/event1 line. That's really all it does. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
Peter Hutterer wrote: On Fri, Jun 12, 2009 at 05:21:53PM +1000, Timothy S. Nelson wrote: On Fri, 12 Jun 2009, Timothy S. Nelson wrote: So, here's my impression of how it works based on what you've just said. [snip] Yuck. Let me do some more reworking. -When a keystroke comes from the hardware, it gets picked up and sent to the client (ie. application/program). - The application program (calling on ???) translates it into a character using the following process: - Translates from a key/scan code into a symbol using the xmodmap map - The translation table is generated from xkb/*. - The compose/locale stuff happens after the xmodmap translation table. Is that better? yeah, close enough, except that in most cases xmodmap has little influence on anything. I can't remember the last time I used it when it wasn't to debug some weird setup from a bugreport. it's something like: 1. server starts up, compiles XKB map for each keyboard device based on xkeyboard-config's files using xkbcomp. 2. clients query server for the XKB map and store it or use it to spread love and/or happiness. 3. key event comes in, driver adds 8 because, hey, why not. also, bonghits. Because values 0-7 gets used for other purposes; it has to do with efforts to save bytes on the wire, and to fit events into 32 byte sizes And we (correctly) discovered there was no keyboard in the world with more than 248 keys, something still at least approximately true 20 years later. Once upon a time, malloc and free were horribly slow (you can't possibly imagine how slow) on some platforms (e.g. VMS). So there are a number of ugly hacks in the protocol encoding (and the Xlib interfaces) to avoid having to do malloc/free on every event, which would have been prohibitive. And even on UNIX of the era, malloc/free was a memory pig (though later I learned that the Berkeley malloc allocator was particularly inefficient if your allocation was size 2^n...). - Jim ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. -Matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
Timothy S. Nelson wrote: It should probably be linked to from http://www.x.org/wiki/XKB but since I don' tappear to have access to do that, If you create an account on the wiki, you should be able to edit - accounts are required to cut down on spam/vandalism, but most pages are editable by anyone with an account. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Matt Hayes wrote: Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. I recently switched to using evdev and when I removed the InputDevice sections from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly named 10-x11-logitech.fdi) containing this: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=ImExPS/2 merge key=input.x11_options.EmulateWheel type=stringtrue/merge merge key=input.x11_options.EmulateWheelButton type=string8/merge /match /device /deviceinfo I constructed that file by looking at mouse-oriented parts of the output of 'lshal' and just stuck the options in where it looked reasonable. It worked, and I'm still amazed. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
walt wrote: Matt Hayes wrote: Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. I recently switched to using evdev and when I removed the InputDevice sections from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly named 10-x11-logitech.fdi) containing this: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=ImExPS/2 merge key=input.x11_options.EmulateWheel type=stringtrue/merge merge key=input.x11_options.EmulateWheelButton type=string8/merge /match /device /deviceinfo I constructed that file by looking at mouse-oriented parts of the output of 'lshal' and just stuck the options in where it looked reasonable. It worked, and I'm still amazed. Well, I will give that a shot. I need to learn how this hal stuff works anyway :) -Matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Build error with latest git LibX11/LibXi
LibX11 ../../../doltcompile gcc -DHAVE_CONFIG_H -I. -I../../../src -I../../../include/X11-I../../../include -I../../../include/X11 -I../../../include -I../../../include/X11 -I../../../src/xcms -I../../../src/xkb -I../../../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -D_BSD_SOURCE -DXIM_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -g -O2 -MT imLcIm.lo -MD -MP -MF .deps/imLcIm.Tpo -c -o imLcIm.lo imLcIm.c imLcIm.c: In function ‘_XimCachedFileName’: imLcIm.c:364: warning: format ‘%03x’ expects type ‘unsigned int’, but argument 6 has type ‘long unsigned int’ imLcIm.c:367: warning: format ‘%03x’ expects type ‘unsigned int’, but argument 6 has type ‘long unsigned int’ imLcIm.c:370: warning: implicit declaration of function ‘open’ imLcIm.c:370: warning: nested extern declaration of ‘open’ imLcIm.c:370: error: ‘O_RDONLY’ undeclared (first use in this function) imLcIm.c:370: error: (Each undeclared identifier is reported only once imLcIm.c:370: error: for each function it appears in.) imLcIm.c:376: warning: implicit declaration of function ‘close’ imLcIm.c:376: warning: nested extern declaration of ‘close’ imLcIm.c:383: warning: implicit declaration of function ‘time’ imLcIm.c:383: warning: nested extern declaration of ‘time’ imLcIm.c:386: warning: implicit declaration of function ‘unlink’ imLcIm.c:386: warning: nested extern declaration of ‘unlink’ imLcIm.c: In function ‘_XimWriteCachedDefaultTree’: imLcIm.c:493: error: ‘O_WRONLY’ undeclared (first use in this function) imLcIm.c:493: error: ‘O_CREAT’ undeclared (first use in this function) imLcIm.c:493: error: ‘O_EXCL’ undeclared (first use in this function) imLcIm.c: In function ‘_XimCreateDefaultTree’: imLcIm.c:530: warning: implicit declaration of function ‘geteuid’ imLcIm.c:530: warning: nested extern declaration of ‘geteuid’ imLcIm.c:531: warning: implicit declaration of function ‘getegid’ imLcIm.c:531: warning: nested extern declaration of ‘getegid’ imLcIm.c:544: error: ‘O_RDONLY’ undeclared (first use in this function) imLcIm.c:559: warning: implicit declaration of function ‘getuid’ imLcIm.c:559: warning: nested extern declaration of ‘getuid’ imLcIm.c:559: warning: implicit declaration of function ‘getgid’ imLcIm.c:559: warning: nested extern declaration of ‘getgid’ make[3]: *** [imLcIm.lo] Error 1 make[3]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules/im/ximcp' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules/im' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules' make: *** [install-recursive] Error 1 - LibXi/Xserver CCxiselectev.o xiselectev.c: In function ‘SProcXISelectEvents’: xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c: In function ‘ProcXISelectEvents’: xiselectev.c:79: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c: In function ‘SProcXIGetSelectedEvents’: xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c:157: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ xiselectev.c: In function ‘ProcXIGetSelectedEvents’: xiselectev.c:178: error: ‘xXIGetSelectedEventsReq’ has no member named ‘window’ make[1]: *** [xiselectev.lo] Error 1 make: *** [all-recursive] Error 1 Making install in Xi CCxiselectev.o xiselectev.c: In function ‘SProcXISelectEvents’: xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no
Re: Strange issue with hal and Xorg
Justin Mattock wrote: On Fri, Jun 12, 2009 at 11:06 AM, Matt Hayesdomin...@slackadelic.com wrote: walt wrote: Matt Hayes wrote: Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. I recently switched to using evdev and when I removed the InputDevice sections from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly named 10-x11-logitech.fdi) containing this: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=ImExPS/2 merge key=input.x11_options.EmulateWheel type=stringtrue/merge merge key=input.x11_options.EmulateWheelButton type=string8/merge /match /device /deviceinfo I constructed that file by looking at mouse-oriented parts of the output of 'lshal' and just stuck the options in where it looked reasonable. It worked, and I'm still amazed. Well, I will give that a shot. I need to learn how this hal stuff works anyway :) -Matt Don't want to confuse you, but hal is being fazed out. udev-142 is now responsible for handling volumeid etc... Yeah.. now I'm confused -Matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
On Fri, Jun 12, 2009 at 11:06 AM, Matt Hayesdomin...@slackadelic.com wrote: walt wrote: Matt Hayes wrote: Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. I recently switched to using evdev and when I removed the InputDevice sections from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly named 10-x11-logitech.fdi) containing this: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=ImExPS/2 merge key=input.x11_options.EmulateWheel type=stringtrue/merge merge key=input.x11_options.EmulateWheelButton type=string8/merge /match /device /deviceinfo I constructed that file by looking at mouse-oriented parts of the output of 'lshal' and just stuck the options in where it looked reasonable. It worked, and I'm still amazed. Well, I will give that a shot. I need to learn how this hal stuff works anyway :) -Matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Don't want to confuse you, but hal is being fazed out. udev-142 is now responsible for handling volumeid etc... -- Justin P. Mattock ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Justin Mattock wrote: Don't want to confuse you, but hal is being fazed out. udev-142 is now responsible for handling volumeid etc... Auuuggh! Just when I'm beginning to understand hal (but not very well.) You've confused me too. How does volumeid relate to a mouse problem? And which docs should I start reading before this actually happens? And have a nice weekend :o) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to run the X xserver in a chroot environment
On Thu, Jun 11, 2009 at 10:54:52PM +0200, Tino Keitel wrote: (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. Have you tried X -configure to generate a usable xorg.conf (inside chroot). And if necessary, adding your own Keyboard and Mouse section like this: Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse EndSection -- Li, Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Current tinderbox regression (xserver)
http://tinderbox.x.org/builds/2009-06-12-0011/logs/xserver/#build xiselectev.c: In function 'SProcXISelectEvents': xiselectev.c:49: error: 'xXISelectEventsReq' has no member named 'window' ... -- Chris Ball c...@laptop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keystroke flow in X.org
On Fri, 12 Jun 2009, Peter Hutterer wrote: yeah, close enough, except that in most cases xmodmap has little influence Ok. s/xmodmap/XKB/ if the physical keyboard changes, the server sends out a keymap notify event and the cycle starts at 2 again. Hopefully, anyway, otherwise the amount of Is this if the keyboard device changes from eg. the first to the second, or is it if you unplug your keyboard and plug in another? Anyway, I've revised the article and diagram; if you could have another skim over, and let me know if there are any other obvious problems, that would be great. Here's the link again: http://computerstuff.jdarx.info/content/keystroke-flow-xorg :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Build error with latest git LibX11/LibXi
http://cgit.freedesktop.org/xorg/proto/inputproto/commit/?id=1d59de593c5aac8e109fcb3c1173d4dc14742dee This change is triggered to fail building the Xserver. it would resolve by this patch. -- diff --git a/Xi/xiselectev.c b/Xi/xiselectev.c index 1259de5..7a16e85 100644 --- a/Xi/xiselectev.c +++ b/Xi/xiselectev.c @@ -46,7 +46,7 @@ SProcXISelectEvents(ClientPtr client) REQUEST(xXISelectEventsReq); swaps(stuff-length, n); REQUEST_AT_LEAST_SIZE(xXISelectEventsReq); -swapl(stuff-window, n); +swapl(stuff-win, n); swaps(stuff-num_masks, n); evmask = (xXIEventMask*)stuff[1]; @@ -76,7 +76,7 @@ ProcXISelectEvents(ClientPtr client) if (stuff-num_masks == 0) return BadValue; -rc = dixLookupWindow(win, stuff-window, client, DixReceiveAccess); +rc = dixLookupWindow(win, stuff-win, client, DixReceiveAccess); if (rc != Success) return rc; @@ -154,7 +154,7 @@ SProcXIGetSelectedEvents(ClientPtr client) REQUEST(xXIGetSelectedEventsReq); swaps(stuff-length, n); REQUEST_SIZE_MATCH(xXIGetSelectedEventsReq); -swapl(stuff-window, n); +swapl(stuff-win, n); return (ProcXIGetSelectedEvents(client)); } @@ -175,7 +175,7 @@ ProcXIGetSelectedEvents(ClientPtr client) REQUEST(xXIGetSelectedEventsReq); REQUEST_SIZE_MATCH(xXIGetSelectedEventsReq); -rc = dixLookupWindow(win, stuff-window, client, DixReceiveAccess); +rc = dixLookupWindow(win, stuff-win, client, DixReceiveAccess); if (rc != Success) return rc; On Fri, 12 Jun 2009 11:33:41 -0700 (PDT) ace102 mgav...@juno.com wrote: LibX11 ../../../doltcompile gcc -DHAVE_CONFIG_H -I. -I../../../src -I../../../include/X11-I../../../include -I../../../include/X11 -I../../../include -I../../../include/X11 -I../../../src/xcms -I../../../src/xkb -I../../../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -D_BSD_SOURCE -DXIM_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -g -O2 -MT imLcIm.lo -MD -MP -MF .deps/imLcIm.Tpo -c -o imLcIm.lo imLcIm.c imLcIm.c: In function ‘_XimCachedFileName’: imLcIm.c:364: warning: format ‘%03x’ expects type ‘unsigned int’, but argument 6 has type ‘long unsigned int’ imLcIm.c:367: warning: format ‘%03x’ expects type ‘unsigned int’, but argument 6 has type ‘long unsigned int’ imLcIm.c:370: warning: implicit declaration of function ‘open’ imLcIm.c:370: warning: nested extern declaration of ‘open’ imLcIm.c:370: error: ‘O_RDONLY’ undeclared (first use in this function) imLcIm.c:370: error: (Each undeclared identifier is reported only once imLcIm.c:370: error: for each function it appears in.) imLcIm.c:376: warning: implicit declaration of function ‘close’ imLcIm.c:376: warning: nested extern declaration of ‘close’ imLcIm.c:383: warning: implicit declaration of function ‘time’ imLcIm.c:383: warning: nested extern declaration of ‘time’ imLcIm.c:386: warning: implicit declaration of function ‘unlink’ imLcIm.c:386: warning: nested extern declaration of ‘unlink’ imLcIm.c: In function ‘_XimWriteCachedDefaultTree’: imLcIm.c:493: error: ‘O_WRONLY’ undeclared (first use in this function) imLcIm.c:493: error: ‘O_CREAT’ undeclared (first use in this function) imLcIm.c:493: error: ‘O_EXCL’ undeclared (first use in this function) imLcIm.c: In function ‘_XimCreateDefaultTree’: imLcIm.c:530: warning: implicit declaration of function ‘geteuid’ imLcIm.c:530: warning: nested extern declaration of ‘geteuid’ imLcIm.c:531: warning: implicit declaration of function ‘getegid’ imLcIm.c:531: warning: nested extern declaration of ‘getegid’ imLcIm.c:544: error: ‘O_RDONLY’ undeclared (first use in this function) imLcIm.c:559: warning: implicit declaration of function ‘getuid’ imLcIm.c:559: warning: nested extern declaration of ‘getuid’ imLcIm.c:559: warning: implicit declaration of function ‘getgid’ imLcIm.c:559: warning: nested extern declaration of ‘getgid’ make[3]: *** [imLcIm.lo] Error 1 make[3]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules/im/ximcp' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules/im' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/media/ubu/Goodone/hax/xorg-checkout/xorg/lib/libX11/modules' make: *** [install-recursive] Error 1 - LibXi/Xserver CCxiselectev.o xiselectev.c: In function ‘SProcXISelectEvents’: xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’ xiselectev.c:49: error: ‘xXISelectEventsReq’ has no member named ‘window’
