Re: XInput: Atmel maXTouch Digitizer touch screen
On 22.12.2011 07:41, Chase Douglas wrote: You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute I did this, but then the clicks by tapping don't work at all anymore. I.e. mouse cursor follows my finger, but I cannot activate anything. Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Do you think I should still proceed this way, given above? You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. Yes, I know. For a start, I'd be quite happy to get a single finger and a nice onscreen keyboard working properly. You mean hid-multitouch or some other one? The hid-multitouch didn't work, because the USD IDs are not registered and apparently the udev rules trich failed as well. I'll try adding the IDs and recompile the kernel, if you think that will make it work properly. Ben ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput: Atmel maXTouch Digitizer touch screen
On 12/22/2011 04:48 AM, Ben Bucksch wrote: On 22.12.2011 07:41, Chase Douglas wrote: You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute I did this, but then the clicks by tapping don't work at all anymore. I.e. mouse cursor follows my finger, but I cannot activate anything. If I had to guess, BTN_TOOL_FINGER is likely still getting in the way of things in the evdev driver. Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Do you think I should still proceed this way, given above? It looks like you need to fix your kernel driver. You could hack up xserver-xorg-input-evdev to disregard the BTN_TOOL_FINGER event, but I would only do that if you can't fix the kernel driver. You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. Yes, I know. For a start, I'd be quite happy to get a single finger and a nice onscreen keyboard working properly. You mean hid-multitouch or some other one? The hid-multitouch didn't work, because the USD IDs are not registered and apparently the udev rules trich failed as well. I'll try adding the IDs and recompile the kernel, if you think that will make it work properly. No, the maXTouch chips are handled by atmel_mx_ts in drivers/input/touchscreen/atmel_mx_ts.c. -- Chase ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.4
One fix required for xinput to work when compiled against newer inputproto headers. Without this fix, xinput will check the server for whichever the current protocol version is (or higher) and fail if that version is not present. If you are updating the inputproto headers to 2.1 or a 2.2RC, you will need this update. Peter Hutterer (2): list: don't use defines for checking server version. xinput 1.5.4 git tag: xinput-1.5.4 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.bz2 MD5: 69cd4dea77915b87c106003668378749 xinput-1.5.4.tar.bz2 SHA1: 4e77f4034aa4bc720726beb0795d77a47a71d2c8 xinput-1.5.4.tar.bz2 SHA256: a8da86f0d7c8ac0c4434e3140ae7f208fc2b35869e5adf10971eef7cb77f4360 xinput-1.5.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.gz MD5: f6b165d11d7c46b7113aaa9ecc380d51 xinput-1.5.4.tar.gz SHA1: 82a3f64f8ec2cca2c1f22247367004727a41864f xinput-1.5.4.tar.gz SHA256: ffdee8ae80e1ad62f266f4e537a9809920fbfca670185cd9131d4896d6fd5035 xinput-1.5.4.tar.gz pgpWRpyC9IOlr.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput: Atmel maXTouch Digitizer touch screen
On Wed, Dec 21, 2011 at 11:52:39PM +0100, Ben Bucksch wrote: I have unsuccessfully tried the whole day to configure the Atmel maXTouch Digitizer with USB ID 03eb:211c . This is a touch screen and does appear in X.org as input device. It is working rudimentary, but bad enough to be unusable. The machine is a Samsung Series 7 Slate XE700T1A, a tablet with standard notebook hardware. I am using Ubuntu 11.10 with Ubuntu kernel 3.0.0-14-generic and xorg-server 1.10.4-1ubuntu4.2. Problems: 1. ABSOLUTE By default, it's configured in Mode RELATIVE, but it's ABSOLUTE. When I do xinput --set-mode Atmel Atmel maXTouch Digitizer ABSOLUTE it works. But I need it at the login screen already. I do not understand how to just change certain config options about an input device without changing the whole config. When I put in /etc/X11/x.org.conf.d/atmel.conf : Section InputClass Identifier Atmel touchscreen MatchProduct Atmel Atmel maXTouch Digitizer MatchIsTouchpad on Option Mode Absolute EndSection then I get a complaint in the X.org log that the Driver is missing (yes, I shouldn't get that and I don't understand why I do). If I use Driver synaptics, X.org log complains that it's not a synaptics device. If I use Driver evdev, the clicking (mouse button, tapping) doesn't at all work anymore. Either way, this should work OOTB. Can somebody please fix the driver to make it know that this device is ABSOLUTE? please attach your log, it's too hard to guess which configuration doesn't apply correctly. 2. Button not released Sometimes, it generates only button 1 pressed, but not button 1 released. as Chase said, probably broken kernel driver or device. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput: Atmel maXTouch Digitizer touch screen
Hey Chase, thanks for your answer. On 22.12.2011 01:41, Chase Douglas wrote: A capture of the evdev events would be necessary to debug the issue. You can use evtest to do this. Done http://www.bucksch.org/xfer/1.evtest The beginning of the log is my finger moving across the screen, in all 4 corners. The end is me tapping on the screen, double-clicking/-tapping, and clicking/tapping long. xinput --list-props 15 gives http://www.bucksch.org/xfer/1.props Xorg.0.log extract http://www.bucksch.org/xfer/Xorg.0.log It needs to conform to what is stated at: Sorry, but I can't judge that. Ben ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput: Atmel maXTouch Digitizer touch screen
On 12/21/2011 09:25 PM, Ben Bucksch wrote: Hey Chase, thanks for your answer. On 22.12.2011 01:41, Chase Douglas wrote: A capture of the evdev events would be necessary to debug the issue. You can use evtest to do this. Done http://www.bucksch.org/xfer/1.evtest Your driver is reporting the availability of BTN_TOOL_FINGER. This is only valid for touchpads. That's why the synaptics driver is loading instead of the evdev driver. You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Hopefully, with either of these two resolutions things will work right. I don't see anything else wrong. You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. I've heard that at least nVidia has switched over to using it, though their previous driver supported multitouch too. -- Chase ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Mon, 24 Oct 2011, Peter Hutterer wrote: On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Hi Peter, Thanks, that put me on the right track. I just had to create /etc/hal/fdi/policy/90-intellipen-pro.fdi with the contents ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device !-- Intellipen Pro -- match key=usb_device.vendor_id int=0x188c match key=usb_device.product_id int=0x221 merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo and /etc/modprobe.d/intellipen.conf with options usbhid quirks=0x188c:0x0221:0x0040 and the device works perfectly. Where should I submit this information so that it gets incorporated to future updates so that others can just plug it in and have it work automatically? Thanks, Tamas ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Mon, Oct 24, 2011 at 01:59:50PM +0200, Tamas Papp wrote: On Mon, 24 Oct 2011, Peter Hutterer wrote: On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Hi Peter, Thanks, that put me on the right track. I just had to create /etc/hal/fdi/policy/90-intellipen-pro.fdi with the contents ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device !-- Intellipen Pro -- match key=usb_device.vendor_id int=0x188c match key=usb_device.product_id int=0x221 merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo and /etc/modprobe.d/intellipen.conf with options usbhid quirks=0x188c:0x0221:0x0040 and the device works perfectly. Where should I submit this information so that it gets incorporated to future updates so that others can just plug it in and have it work automatically? kernel bugzilla. I'd be easy enough to knock up a kernel patch that adds the quirk for this particular device, so if you can find the time to do that you're most likely to see the change happen. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Fri, 21 Oct 2011, Tamas Papp wrote: and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: $ xinput test 21 # (excerpt) motion a[0]=1130 a[1]=525 a[2]=946 a[3]=0 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 button press 1 motion a[0]=1130 a[1]=525 a[2]=1002 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1012 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1021 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 Is there a way I could remap these to the appropriate axes so that the cursor would move on the screen? Sorry if this is a dumb question, I know very little about Xinput internals. xorg.conf or command line snippets or documentation on how to do this would be appreciated. I tried xinput set-prop but couldn't figure it out. Hi, I found a thread in the archives that talks about a similar problem: http://www.mail-archive.com/xorg@lists.freedesktop.org/msg09731.html $ cat /proc/bus/input/devices reports I: Bus=0003 Vendor=188c Product=0221 Version=1001 N: Name=EPOS EPOS Pen Digitizer. P: Phys=usb-:00:1d.0-2/input0 S: Sysfs=/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/input/input41 U: Uniq= H: Handlers=mouse1 event23 B: PROP=0 B: EV=1b B: KEY=c01 7001f 0 0 0 0 B: ABS=ff00010f B: MSC=10 but I am still unclear on what I should do to solve this. Best, Tamas ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
remapping XInput axes
Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: $ xinput list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ Microsoft Microsoft® Nano Transceiver v2.0id=12 [slave pointer (2)] ⎜ ↳ Microsoft Microsoft® Nano Transceiver v2.0id=13 [slave pointer (2)] ⎜ ↳ DualPoint Stick id=16 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=17 [slave pointer (2)] ⎜ ↳ Dell BT Keyboard id=20 [slave pointer (2)] ⎜ ↳ EPOS EPOS Pen Digitizer. id=21 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Video Bus id=6[slave keyboard (3)] ↳ Power Button id=7[slave keyboard (3)] ↳ Sleep Button id=8[slave keyboard (3)] ↳ HID 413c:8157 id=9[slave keyboard (3)] ↳ Integrated_Webcam_2M id=10 [slave keyboard (3)] ↳ Microsoft Microsoft® Nano Transceiver v2.0id=11 [slave keyboard (3)] ↳ HID 046a:0011 id=14 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=15 [slave keyboard (3)] ↳ Dell WMI hotkeys id=18 [slave keyboard (3)] ↳ ACPI Virtual Keyboard Device id=19 [slave keyboard (3)] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: $ xinput test 21 # (excerpt) motion a[0]=1130 a[1]=525 a[2]=946 a[3]=0 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 button press 1 motion a[0]=1130 a[1]=525 a[2]=1002 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1012 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1021 a[3]=92 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1031 a[3]=90 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1042 a[3]=90 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1052 a[3]=89 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1062 a[3]=86 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 motion a[0]=1130 a[1]=525 a[2]=1072 a[3]=85 a[4]=0 a[5]=0 motion a[6]=0 a[7]=0 a[8]=0 a[9]=0 a[10]=0 a[11]=0 motion a[12]=0 Is there a way I could remap these to the appropriate axes so that the cursor would move on the screen? Sorry if this is a dumb question, I know very little about Xinput internals. xorg.conf or command line snippets or documentation on how to do this would be appreciated. I tried xinput set-prop but couldn't figure it out. I attach the output of xinput list-props and xinput list --long for this device. Best, Tamas Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Button Labels (266):Button Left (135), Button Middle (136), Button Right (137), Button Wheel Up (138), Button Wheel Down (139), Button Horiz Wheel Left (140), Button Horiz Wheel Right (141), Button 3 (725), Button 4 (726) Evdev Middle Button Emulation (267):0 Evdev Middle Button Timeout (268): 50 Evdev Wheel Emulation (269):0 Evdev Wheel Emulation Axes (270): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (271):10 Evdev Wheel Emulation Timeout (272):200 Evdev Wheel Emulation Button (273): 4 Evdev Drag Lock Buttons (274): 0 ⎜ ↳ EPOS EPOS Pen Digitizer. id=21 [slave pointer (2)] Reporting 14 classes: Class
Re: xinput - core pointer - Transformation?
Thnaks for answering my request. Well it does not seem to be a Problem with Xournal - it ist the same with the current stable and the development version. Furthermore it ist the same problem with GIMP when i activate the Xinput. So is there any information onf how the pointer gets transformed? best regards roman Am 2011-09-30 07:20, schrieb Peter Hutterer: On Wed, Sep 28, 2011 at 11:36:41PM +0200, roman wrote: Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? I don't quite understand. Changing the device matrix should also change the XI coordinates and map them into the same range. What isn't working here? Does xournal scale somehow differently again? Cheers, Peter -- mail ro...@granul.at webhttp://granul.at tel+43-650-2041643 jabber r...@jabber.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xinput - core pointer - Transformation?
On Thu, Oct 13, 2011 at 01:51:26PM +0200, Roman Seidl wrote: Thnaks for answering my request. Well it does not seem to be a Problem with Xournal - it ist the same with the current stable and the development version. Furthermore it ist the same problem with GIMP when i activate the Xinput. So is there any information onf how the pointer gets transformed? dix/getevents.c:transformAbsolute() in the server. The theory is that for any coordinate x/y that the driver posts the actual event coordinates given a matrix M are x(m)/y(m). So you should never see the original coordinates. Simplest example, a driver with range 0..100 that has a matrix mapping to the left 50% should only ever have 0..50 in the events. Provided the server does this correctly, the rest is in the client side. Cheers, Peter best regards roman Am 2011-09-30 07:20, schrieb Peter Hutterer: On Wed, Sep 28, 2011 at 11:36:41PM +0200, roman wrote: Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? I don't quite understand. Changing the device matrix should also change the XI coordinates and map them into the same range. What isn't working here? Does xournal scale somehow differently again? Cheers, Peter -- mail ro...@granul.at webhttp://granul.at tel+43-650-2041643 jabber r...@jabber.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xinput - core pointer - Transformation?
On Wed, Sep 28, 2011 at 11:36:41PM +0200, roman wrote: Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? I don't quite understand. Changing the device matrix should also change the XI coordinates and map them into the same range. What isn't working here? Does xournal scale somehow differently again? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
xinput - core pointer - Transformation?
Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? cheers roman ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
xinput core poiner?
I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sound nice BUT i want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: how to disable SendCoreEvents for specific xinput-dev
On Fri, Mar 25, 2011 at 08:05:42PM +0100, Rieker Flaik wrote: Hi, how to disable SendCoreEvents for a specific mouse that can be listed by xinput list? I tried unsuccessfully: $ xinput set-int-prop 10 SendCoreEvents 8 0 I use debian stable (squeezy) with X.Org 7.5 xinput --float device name Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
xorg-devel patch is working. Thank s. [PATCH] xfree86: swap the order to-be-merged lists in xf86CollectInputOptions. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
Hi, Oh, forgot to mention the sources are from git tree, the patch is there, same problem again. Thanks, S. A british laptop layout is not recognized since a couple of weeks with compilation from git. Section InputClass IdentifierAT Keyboard MatchProductAT Translated Set 2 keyboard MatchIsKeyboardon Driverevdev OptionAutoServerLayouton OptionAutoRepeat500 30 OptionXkbRulesxorg OptionXkbModelpc104 OptionXkbLayoutgb OptionXkbVariantbasic,winkeys EndSection What can be done? commit beea2378f142556471c62290e275935af848e137 Author: Peter Hutterer peter.hutte...@who-t.net Date: Mon Dec 6 14:33:43 2010 +1000 xfree86: don't overwrite option list (#32115) Options set in the configuration file were unconditionally overwritten by the server. Merge the already existing options and the new options together instead of just overwriting ones. http://bugs.freedesktop.org/show_bug.cgi?id=32115 Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
On 12/09/2010 01:22 AM, Peter Hutterer wrote: What can be done? commit beea2378f142556471c62290e275935af848e137 Author: Peter Hutterer peter.hutte...@who-t.net Date: Mon Dec 6 14:33:43 2010 +1000 xfree86: don't overwrite option list (#32115) Options set in the configuration file were unconditionally overwritten by the server. Merge the already existing options and the new options together instead of just overwriting ones. http://bugs.freedesktop.org/show_bug.cgi?id=32115 Yeah, I also assumed that would fix the problem but unfortunately it didn't. Maybe I can help track it down further? FWIW, setxkbmap -rules evdev -layout de -variant nodeadkeys fixes the problem for me. I haven't tried but as a workaround you may have luck when putting it in your .xinitrc. Cheers, Simon ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
Hi, A british laptop layout is not recognized since a couple of weeks with compilation from git. Section InputClass Identifier AT Keyboard MatchProductAT Translated Set 2 keyboard MatchIsKeyboard on Driver evdev Option AutoServerLayout on Option AutoRepeat500 30 Option XkbRules xorg Option XkbModel pc104 Option XkbLayout gb Option XkbVariantbasic,winkeys EndSection What can be done? Thanks, S. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
On Wed, Dec 08, 2010 at 08:08:48AM -0800, Sebastian Glita wrote: A british laptop layout is not recognized since a couple of weeks with compilation from git. Section InputClass Identifier AT Keyboard MatchProductAT Translated Set 2 keyboard MatchIsKeyboard on Driver evdev Option AutoServerLayout on Option AutoRepeat500 30 Option XkbRules xorg Option XkbModel pc104 Option XkbLayout gb Option XkbVariantbasic,winkeys EndSection What can be done? commit beea2378f142556471c62290e275935af848e137 Author: Peter Hutterer peter.hutte...@who-t.net Date: Mon Dec 6 14:33:43 2010 +1000 xfree86: don't overwrite option list (#32115) Options set in the configuration file were unconditionally overwritten by the server. Merge the already existing options and the new options together instead of just overwriting ones. http://bugs.freedesktop.org/show_bug.cgi?id=32115 Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.3
Is it a bird? Is it a plane? No, neither usually arrives via email. It's just another version of xinput. Really, what did you expect? This release brings a minor fix when checking for the device mode. Out-of-proximity device could report the wrong mode. The UI has two minor improvements. First, it doesn't interpret random strings as relative anymore when switching modes. Second, valuators are printed on separate lines now with the valuator number prefixed. This is helpful for devices that don't always report continuous valuator ranges. Chase Douglas (1): xinput: Split XI2 valuators and print index of events Peter Hutterer (3): list: only check the last bit in the device mode. Print an error if mode is neither ABSOLUTE nor RELATIVE. xinput 1.5.3 git tag: xinput-1.5.3 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.3.tar.bz2 MD5: 1e2f0ad4f3fa833b65c568907f171d28 xinput-1.5.3.tar.bz2 SHA1: 70f258279acaa45fb77820ae3f8c2bee9f2d2235 xinput-1.5.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.3.tar.gz MD5: 87ad4db2fad4ff9a68e57759a63abc4b xinput-1.5.3.tar.gz SHA1: 01f854885795bb9d55e540046f55dfaf7875db37 xinput-1.5.3.tar.gz pgpYeJ3mXOpSI.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput
On 11/05/10 00:21, Peter Hutterer wrote: On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Wouldn't the config backend be in an ideal position to create reasonably stable identifiers? If one can be built, the backend might add an input property, e.g. Device Stable Identifier. Would you like to see such a patch? Cheers, Simon ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput
On Sun, Nov 07, 2010 at 02:56:51PM +0100, Simon Thum wrote: On 11/05/10 00:21, Peter Hutterer wrote: On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Wouldn't the config backend be in an ideal position to create reasonably stable identifiers? If one can be built, the backend might add an input property, e.g. Device Stable Identifier. Would you like to see such a patch? Peter Korsgaard wrote one ages ago, see the link below. http://lists.x.org/archives/xorg-devel/2010-May/008348.html main problem is that there's no platform-independent way for the stable identifiers Peter suggested. adding vendor/device id is an alternative solution, but you lose out once you plug two identical devices in. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput
On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Cheers, Peter When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput
On 05/11/10 10:21, Peter Hutterer wrote: On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Cheers, Peter When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. Hi, A unique ID would be useful. I found this in linux-2.6.31.1/drivers/input/evdev.c: if (_IOC_NR(cmd) == _IOC_NR(EVIOCGUNIQ(0))) return str_to_user(dev-uniq, _IOC_SIZE(cmd), p); It was not clear how to integrate it in to xf86-input-evdev/src/evdev.c When i start a program that uses a left-hand puck (i'm using a mouse) and a normal right-hand mouse, i'll have to make a pop-up widget appear every time so that the user can choose which mouse does what. It would be good if the application can store the settings for a unique device id. I used to use this mouse and puck arrangement around 1990 on a Human Interface Loop Bus (HIL Bus) on a HP 9000 Apollo workstation. It was a standard way of running CAD programs and greatly reduced mouse-finger fatigue. The software was killed for political reasons, but the useability was far better than the toy Windows stuff around now. http://wiki.parisc-linux.org/HIL ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput device properties ; keymaps service console switch
Hi, two other notes on VT switching: - using a linux livedvd which yields for `Xorg -version' : X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.29-hardened-r1 x86_64 Build Date: 01 October 2009 04:33:09PM restarting keymaps service has *NO* effect to ALT+F2 bound in the desktop environment to present a window to launch commands (CTRL+ALT+F1..12 does VT switching); - launching fbsplash as root in xterm (although for nothing) yields the same negative effect of having ALT+F1..12 do VT switch (without CTRL key pressed) for currently `Xorg -version' : X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.35-tuxonice-r1 x86_64 [...] Current Operating System: Linux localhost 2.6.35-tuxonice-r3 #3 SMP [...] 2010 x86_64 Kernel command line: [...] dolvm real_root=/dev/mapper/linux-root usbcore.autosuspend=1 pcie_aspm.policy=powersave tpm_tis.itpm=yes acpi_osi=Linux processor.max_cstate=2 [...] snd_hda_intel.power_save=1 quiet init_opts=3 CONSOLE=/dev/tty fbcon=scrollback:256k splash=verbose,theme:tuxonice real_resume=/dev/sda2 resume=swap:/dev/sda2 Build Date: [...] September 2010 [...] What part in the X server source code might be responsible? Thank s. - Original Message From: Peter Hutterer peter.hutte...@who-t.net To: Sebastian Glita gls...@yahoo.com Cc: xorg@lists.freedesktop.org Sent: Mon, August 23, 2010 2:28:06 AM Subject: Re: XInput device properties ; keymaps service console switch 2. When I restart keymaps service like this: u...@localhost ~ $ #eselect rc restart keymaps u...@localhost ~ $ /etc/init.d/keymaps restart then whenever I press: - F1..12 keys or - Alt+F1..12 or - the windows key, whether Control (CTRL) key is pressed or released, it doesn't matter, I get a console switch each time. what does xev say about key presses? is the ctrl key stuck? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput device properties ; keymaps service console switch
Hi, 2. Sorry, it was only F1..F12+ALT and windows key, not just F1..F12. I inserted xev output below, I pressed/released Ctrl a couple of times; then pressed/released the windows key twice: each time I got a VT switch, I used ALT+F7 to switch from console to Xorg back again. Same would happen with ALT+F1..12 or menu key instead of Super_L. It seems Ctrl key is not stuck. Thanks, s. KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38536800, (35,29), root:(306,317), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38536863, (35,29), root:(306,317), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38537358, (35,29), root:(306,317), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38537438, (35,29), root:(306,317), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityFullyObscured KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38538700, (35,29), root:(306,317), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38538707, (35,29), root:(306,317), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityPartiallyObscured Expose event, serial 31, synthetic NO, window 0x501, (0,0), width 178, height 10, count 5 Expose event, serial 31, synthetic NO, window 0x501, (0,10), width 10, height 58, count 4 Expose event, serial 31, synthetic NO, window 0x501, (68,10), width 110, height 58, count 3 Expose event, serial 31, synthetic NO, window 0x501, (0,68), width 178, height 106, count 2 Expose event, serial 31, synthetic NO, window 0x501, (1,174), width 176, height 3, count 1 Expose event, serial 31, synthetic NO, window 0x501, (2,177), width 174, height 1, count 0 VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityFullyObscured MappingNotify event, serial 31, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38540632, (35,29), root:(306,317), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38540640, (35,29), root:(306,317), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 32, synthetic NO, window 0x501, state VisibilityPartiallyObscured Expose event, serial 32, synthetic NO, window 0x501, (0,0), width 178, height 10, count 5 Expose event, serial 32, synthetic NO, window 0x501, (0,10), width 10, height 58, count 4 Expose event, serial 32, synthetic NO, window 0x501, (68,10), width 110, height 58, count 3 Expose event, serial 32, synthetic NO, window 0x501, (0,68), width 178, height 106, count 2 Expose event, serial 32, synthetic NO, window 0x501, (1,174), width 176, height 3, count 1 Expose event, serial 32, synthetic NO, window 0x501, (2,177), width 174, height 1, count 0 MotionNotify event, serial 32, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38549990, (35,29), root:(306,317), state 0x0, is_hint 0, same_screen YES On Sat, Aug 21, 2010 at 07:31:21AM -0700, Sebastian Glita wrote: Hi, When using CTRL+ALT+F1..12 to switch between consoles and Xorg, it happens that: 1. When I do like this: u...@localhost ~ $ xinput set-int-prop 'ImPS/2 Generic Wheel Mouse' 'Device Enabled' 8 0 u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic
Re: XInput device properties ; keymaps service console switch
On Sat, Aug 21, 2010 at 07:31:21AM -0700, Sebastian Glita wrote: Hi, When using CTRL+ALT+F1..12 to switch between consoles and Xorg, it happens that: 1. When I do like this: u...@localhost ~ $ xinput set-int-prop 'ImPS/2 Generic Wheel Mouse' 'Device Enabled' 8 0 u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 0 and then switch to console (CTRL+ALT+F1) and then back again, I get this: u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 1 So the properties' values change betwen console switching. VT switching disables all devices and re-enables them when coming back. It's been like this for ages and I'm not really inclined to change this behaviour at this point. Generally, any use of xinput is a once-off effect only and the setting set by xinput is not guaranteed to be maintained and/or monitored for changes. 2. When I restart keymaps service like this: u...@localhost ~ $ #eselect rc restart keymaps u...@localhost ~ $ /etc/init.d/keymaps restart then whenever I press: - F1..12 keys or - Alt+F1..12 or - the windows key, whether Control (CTRL) key is pressed or released, it doesn't matter, I get a console switch each time. what does xev say about key presses? is the ctrl key stuck? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
XInput device properties ; keymaps service console switch
Hi, When using CTRL+ALT+F1..12 to switch between consoles and Xorg, it happens that: 1. When I do like this: u...@localhost ~ $ xinput set-int-prop 'ImPS/2 Generic Wheel Mouse' 'Device Enabled' 8 0 u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 0 and then switch to console (CTRL+ALT+F1) and then back again, I get this: u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 1 So the properties' values change betwen console switching. 2. When I restart keymaps service like this: u...@localhost ~ $ #eselect rc restart keymaps u...@localhost ~ $ /etc/init.d/keymaps restart then whenever I press: - F1..12 keys or - Alt+F1..12 or - the windows key, whether Control (CTRL) key is pressed or released, it doesn't matter, I get a console switch each time. Ok, so I get these versions: u...@localhost ~ $ Xorg -version X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.35-tuxonice x86_64 Gentoo Current Operating System: Linux localhost 2.6.35-tuxonice #1 SMP Fri Aug 20 21:38:27 EEST 2010 x86_64 Kernel command line: auto BOOT_IMAGE=Gentoo2.6 ro root=801 root=/dev/sda1 real_resume=/dev/sda2 resume=swap:/dev/sda2 usbcore.autosuspend=1 intel_iommu=off fb=no quiet CONSOLE=/dev/tty init_opts=3 fbcon=scrollback:256k splash=verbose,theme:tuxonice Build Date: 21 August 2010 06:33:53AM Current version of pixman: 0.19.3 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Thanks, appreciate, s. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Fwd: Questions about xinput calibrator
I was working with a linux user who uses Puppy Linux Quirky 1.2 and wished to hook it up to touchscreens. We were experimenting with xinput calibrator, but he advised me that the screen is not calibrated after using it (I did note that the values given by xinput_calibrator_x86 did change. Originally it was 0 to 16384 on x/y, and after it was around the 5000-15000 mark (approx). Just to make sure, I did make xorg flip the axis around since x/y axis were inverted. I was not able to find much information on the xinput calibrator other then the homepage http://www.freedesktop.org/wiki/Software/xinput_calibrator, Thank you. -- Nathan Coulson (conathan) -- Location: Brittish Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- Nathan Coulson (conathan) -- Location: Brittish Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.2
Second stable release for xinput 1.5. A slight behavioural change, if a device name is ambiguous the XI2 path of xinput will refuse to change anything - just like the XI1 paths already did anyway. To handle ambiguous devices that register as pointer and keyboard with the same name (like many mouse/keyboard combos do), you can now also specify the device ID with a pointer: and keyboard: prefix. For example: xinput --list-props pointer:device name Kees Cook (1): Atoms from XIGetProperty are 32bits (#27657) Peter Hutterer (2): test-xi2: Print out the sourceid for enter/leave events. xinput 1.5.2 Will Thompson (2): Warn and fail if a device name is ambiguous. Support pointer: and keyboard: prefices for XI2 device names Yaakov Selkowitz (2): man: Use AC_PROG_SED to find sed man: use automake silent rules git tag: xinput-1.5.2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.2.tar.bz2 MD5: 8cec6023f90180cb8e4be31d98c43fda xinput-1.5.2.tar.bz2 SHA1: 4b352ad59e67dc6e63361a9050d3fbe5a6aec3de xinput-1.5.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.2.tar.gz MD5: 8b44fd41e5faab6db8364783a01c928b xinput-1.5.2.tar.gz SHA1: 8ee781cdba5ff28dc58f1d2e2528d9a43b6566cb xinput-1.5.2.tar.gz pgpfM6Dq1PhKG.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xinput 1.5.2
Second stable release for xinput 1.5. A slight behavioural change, if a device name is ambiguous the XI2 path of xinput will refuse to change anything - just like the XI1 paths already did anyway. To handle ambiguous devices that register as pointer and keyboard with the same name (like many mouse/keyboard combos do), you can now also specify the device ID with a pointer: and keyboard: prefix. For example: xinput --list-props pointer:device name Kees Cook (1): Atoms from XIGetProperty are 32bits (#27657) Peter Hutterer (2): test-xi2: Print out the sourceid for enter/leave events. xinput 1.5.2 Will Thompson (2): Warn and fail if a device name is ambiguous. Support pointer: and keyboard: prefices for XI2 device names Yaakov Selkowitz (2): man: Use AC_PROG_SED to find sed man: use automake silent rules git tag: xinput-1.5.2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.2.tar.bz2 MD5: 8cec6023f90180cb8e4be31d98c43fda xinput-1.5.2.tar.bz2 SHA1: 4b352ad59e67dc6e63361a9050d3fbe5a6aec3de xinput-1.5.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.2.tar.gz MD5: 8b44fd41e5faab6db8364783a01c928b xinput-1.5.2.tar.gz SHA1: 8ee781cdba5ff28dc58f1d2e2528d9a43b6566cb xinput-1.5.2.tar.gz pgpTNeLhQbWfD.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problem with RECORD, XInput(2) (and Xnee)
Thanks a lot. That clarified it :) Xnee can now record the device events from Xinput. Some work remains though with the non device events. A basic replay (XTest) of multiple pointers seems to be working as well. .. and about implementing XI2 in RECORD. I'd love to do it, but as most of us currently (or constantly) I am lacking the time to do it. But some fine day. /hesa On 05/25/2010 04:21 AM, Peter Hutterer wrote: On Tue, May 25, 2010 at 12:36:38AM +0200, Henrik Sandklef wrote: hi I am currently implementing support for XInput(2) devices in GNU Xnee, starting out with recording events. Xnee gets copies of events from the X Server (using the RECORD extension). It seems to be a problem in the RECORD extension regarding XI (or XI(2)), but I am not sure and it would be great to get feedback. I'll try to describe the problem as good as I can. --- When reading the XInput spec and the corresponding source code I understand it as one XI2 event is packed into two normal events. I started by implementing support for MotionEvents. This worked out rather well. Xnee receives four normal events and packs them into two XI2 events (one from the master and one from the slave) and prints them out. I think you may be mixing up XI2 and XI 1.x here. XI 1.x does indeed that. The limitations on event size to 32 bits means only some valuators fit into the first event a flag (highest bit in device-id) in the first event specifies if there are more to come (the others are of type DeviceValuator). Xlib packs those together into one event. XI2 uses GenericEvents exclusively which work very different, all of type 35 and you need to watch the extension field and -more importantly- the lenght field because you may need to pull down more data. See the event cookie mechanisms in Xlib. Having said that, I don't think RECORD writes XI2 events onto the wire at the moment, so that point is moot. When moving a pointer one pixel Xnee gets (event, detail): 83 detail=0 78 detail=9 83 detail=0 78 detail=13 The event base for XI is 78, so it looks ok to me. The detail is set to the deviceid of the input device (when not 0). 83 is the motion event then, 78 is the DeviceValuator event, the above are two separate motion events. Look up the protocol spec for DeviceValuator, IIRC it's described there how the events are squashed together. if you have a large number of valuators, you'd get 83 78 78 78 83 78 78 78, etc. But when adding support for ButtonPress and ButtonRelease I don't get the 4 events for every press (or release). And the detail is always set to the number of the button pressed. When pressing a button Xnee gets (event, detail): 81 detail=1 81 detail=1 82 detail=2 82 detail=2 two button presses, two button releases. Likely because you're seeing the master and the slave device events - they should have different deviceids. we don't send valuators down after those events because the drivers usually send motion events before the button events, so the actual button events don't contain valuator data and hence no trailing DeviceValuators. When reading the source code of XInputWireToEvent (libXi/src/XExtInt.c) it looks as if the client side of XI does pack two events together to one. Since RECORD doesn't give Xnee normal client side events (as normal apps get from client libs) but rather limited copies directly from the server, it seems to be something odd in the RECORD extension (or with my code). Most of my tests are done using swinput (Linux module) with support for 8 input devices, but I've tested with real devices as well. you can freely use software-emulated devices, there's no difference at this level anymore. so yeah, you're close but you need to distinguish between master and slave devices (or not, depending on what's needed). And as I said above, you're working against XI 1.5 here. Though updating RECORD to transmit XI2 events as well wouldn't be a bad project if you're interested. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: h...@sandklef.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Problem with RECORD, XInput(2) (and Xnee)
hi I am currently implementing support for XInput(2) devices in GNU Xnee, starting out with recording events. Xnee gets copies of events from the X Server (using the RECORD extension). It seems to be a problem in the RECORD extension regarding XI (or XI(2)), but I am not sure and it would be great to get feedback. I'll try to describe the problem as good as I can. --- When reading the XInput spec and the corresponding source code I understand it as one XI2 event is packed into two normal events. I started by implementing support for MotionEvents. This worked out rather well. Xnee receives four normal events and packs them into two XI2 events (one from the master and one from the slave) and prints them out. When moving a pointer one pixel Xnee gets (event, detail): 83 detail=0 78 detail=9 83 detail=0 78 detail=13 The event base for XI is 78, so it looks ok to me. The detail is set to the deviceid of the input device (when not 0). But when adding support for ButtonPress and ButtonRelease I don't get the 4 events for every press (or release). And the detail is always set to the number of the button pressed. When pressing a button Xnee gets (event, detail): 81 detail=1 81 detail=1 82 detail=2 82 detail=2 When reading the source code of XInputWireToEvent (libXi/src/XExtInt.c) it looks as if the client side of XI does pack two events together to one. Since RECORD doesn't give Xnee normal client side events (as normal apps get from client libs) but rather limited copies directly from the server, it seems to be something odd in the RECORD extension (or with my code). Most of my tests are done using swinput (Linux module) with support for 8 input devices, but I've tested with real devices as well. Any input is welcome. regards, Henrik Sandklef GNU Xnee version: Latest on Branch: xinput2-support with some minor local modifications My system: name of display::2.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10706000 X.Org version: 1.7.6 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x324, revert to Parent number of extensions:27 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problem with RECORD, XInput(2) (and Xnee)
On Tue, May 25, 2010 at 12:36:38AM +0200, Henrik Sandklef wrote: hi I am currently implementing support for XInput(2) devices in GNU Xnee, starting out with recording events. Xnee gets copies of events from the X Server (using the RECORD extension). It seems to be a problem in the RECORD extension regarding XI (or XI(2)), but I am not sure and it would be great to get feedback. I'll try to describe the problem as good as I can. --- When reading the XInput spec and the corresponding source code I understand it as one XI2 event is packed into two normal events. I started by implementing support for MotionEvents. This worked out rather well. Xnee receives four normal events and packs them into two XI2 events (one from the master and one from the slave) and prints them out. I think you may be mixing up XI2 and XI 1.x here. XI 1.x does indeed that. The limitations on event size to 32 bits means only some valuators fit into the first event a flag (highest bit in device-id) in the first event specifies if there are more to come (the others are of type DeviceValuator). Xlib packs those together into one event. XI2 uses GenericEvents exclusively which work very different, all of type 35 and you need to watch the extension field and -more importantly- the lenght field because you may need to pull down more data. See the event cookie mechanisms in Xlib. Having said that, I don't think RECORD writes XI2 events onto the wire at the moment, so that point is moot. When moving a pointer one pixel Xnee gets (event, detail): 83 detail=0 78 detail=9 83 detail=0 78 detail=13 The event base for XI is 78, so it looks ok to me. The detail is set to the deviceid of the input device (when not 0). 83 is the motion event then, 78 is the DeviceValuator event, the above are two separate motion events. Look up the protocol spec for DeviceValuator, IIRC it's described there how the events are squashed together. if you have a large number of valuators, you'd get 83 78 78 78 83 78 78 78, etc. But when adding support for ButtonPress and ButtonRelease I don't get the 4 events for every press (or release). And the detail is always set to the number of the button pressed. When pressing a button Xnee gets (event, detail): 81 detail=1 81 detail=1 82 detail=2 82 detail=2 two button presses, two button releases. Likely because you're seeing the master and the slave device events - they should have different deviceids. we don't send valuators down after those events because the drivers usually send motion events before the button events, so the actual button events don't contain valuator data and hence no trailing DeviceValuators. When reading the source code of XInputWireToEvent (libXi/src/XExtInt.c) it looks as if the client side of XI does pack two events together to one. Since RECORD doesn't give Xnee normal client side events (as normal apps get from client libs) but rather limited copies directly from the server, it seems to be something odd in the RECORD extension (or with my code). Most of my tests are done using swinput (Linux module) with support for 8 input devices, but I've tested with real devices as well. you can freely use software-emulated devices, there's no difference at this level anymore. so yeah, you're close but you need to distinguish between master and slave devices (or not, depending on what's needed). And as I said above, you're working against XI 1.5 here. Though updating RECORD to transmit XI2 events as well wouldn't be a bad project if you're interested. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
patch for xorg-xinput-fpit
Hi, i ran into a wired behavior with xorg-xinput-fpit. system compaq tc1000, ubuntu 10.04 seem that maxY ist assigned to maxX. see pastebin: http://pastebin.com/pZC3c16Q thanks, philip created a diff to correct the problem: diff --git a/src/xf86Fpit.c b/src/xf86Fpit.c index ce7540b..4c09c96 100644 --- a/src/xf86Fpit.c +++ b/src/xf86Fpit.c @@ -232,7 +232,7 @@ static void xf86FpitSetUpAxes(DeviceIntPtr dev, FpitPrivateP #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 axis_labels[0], #endif - priv-fpitMinY, priv-fpitMaxY, 9500, 0 / + priv-fpitMinX, priv-fpitMaxX, 9500, 0 / 9500 /* max_res */ ); InitValuatorAxisStruct(dev, 1, #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 -- ICQ# 609508529, IRC: phil...@chat.freenode.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch for xorg-xinput-fpit
On Tue, May 18, 2010 at 09:43:36AM +0200, Philip wrote: Hi, i ran into a wired behavior with xorg-xinput-fpit. system compaq tc1000, ubuntu 10.04 seem that maxY ist assigned to maxX. see pastebin: http://pastebin.com/pZC3c16Q thanks, philip created a diff to correct the problem: diff --git a/src/xf86Fpit.c b/src/xf86Fpit.c index ce7540b..4c09c96 100644 --- a/src/xf86Fpit.c +++ b/src/xf86Fpit.c @@ -232,7 +232,7 @@ static void xf86FpitSetUpAxes(DeviceIntPtr dev, FpitPrivateP #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 axis_labels[0], #endif - priv-fpitMinY, priv-fpitMaxY, 9500, 0 / + priv-fpitMinX, priv-fpitMaxX, 9500, 0 / 9500 /* max_res */ ); InitValuatorAxisStruct(dev, 1, #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 thanks, looks good. Please have a look at http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches though and re-send this as a patch generated by git-format patch (signed off). I'll push it asap then. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch for xorg-xinput-fpit
On Tue, 18 May 2010 21:10:00 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: thanks, looks good. Please have a look at http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches though and re-send this as a patch generated by git-format patch (signed off). I'll push it asap then. Cheers, Peter Thanks Peter, i will do my best... -- Philip feu...@uni-koblenz.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH] evdev: add 3x3 transformation matrix xinput property for multi-head handling
For absolute input devices (E.G. touchscreens) in multi-head setups, we
need a way to bind the device to an randr output. This adds the
infrastructure to evdev to allow us to do so.
The X server scales input coordinates to the dimensions of the shared
(total) frame buffer, so to restrict motion to an output we need to
scale/rotate/translate device coordinates to a subset of the frame buffer
before passing them on to the X server.
This is done here using a 3x3 transformation matrix, which is applied to
the device coordinates using homogeneous coordinates, E.G.:
[ c0 c1 c2 ] [ x ]
[ c3 c4 c5 ] * [ y ]
[ c6 c7 c8 ] * [ 1 ]
Notice: As input devices have varying input ranges, the coordinates are first
scaled to the [0..1] range for generality, and afterwards scaled back up.
E.G. for a dual head setup (using same resolution) next to each other, you
would want to scale the X coordinates of touchscreen connected to the
both heads by 50%, and translate (offset) the coordinates of the rightmost
head by 50%, or in matrix form:
left: right:
[ 0.5 0 0 ] [ 0.5 0 0.5 ]
[ 0 1 0 ] [ 0 1 0 ]
[ 0 0 1 ] [ 0 0 0 ]
Which can be done using xinput:
xinput set-prop left --type=float Evdev Coordinate Transformation Matrix \
0.5 0 0 0 1 0 0 0 1
xinput set-prop right --type=float Evdev Coordinate Transformation Matrix \
0.5 0 0.5 0 1 0 0 0 1
This is general enough to replace the various tweaks we have in evdev
(InvertX/Y, Calibration, SwapAxes), but I have left them for now.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
include/evdev-properties.h |7 ++
man/evdev.man | 13
src/evdev.c| 138 +++-
src/evdev.h|2 +
4 files changed, 159 insertions(+), 1 deletions(-)
diff --git a/include/evdev-properties.h b/include/evdev-properties.h
index 7df2876..7417a5b 100644
--- a/include/evdev-properties.h
+++ b/include/evdev-properties.h
@@ -66,4 +66,11 @@
/* BOOL */
#define EVDEV_PROP_SWAP_AXES Evdev Axes Swap
+/* Coordinate transformation matrix */
+/* FLOAT, 9 values in row-major order, coordinates in 0..1 range: */
+/* [c0 c1 c2] [x] */
+/* [c5 c4 c5] * [y] */
+/* [c6 c7 c8] [1] */
+#define EVDEV_PROP_TRANSFORM Evdev Coordinate Transformation Matrix
+
#endif
diff --git a/man/evdev.man b/man/evdev.man
index 49ab12c..21d7aa4 100644
--- a/man/evdev.man
+++ b/man/evdev.man
@@ -161,6 +161,15 @@ originally reported by the kernel (e.g. touchscreens). The
scaling to the
custom coordinate system is done in-driver and the X server is unaware of
the transformation. Property: Evdev Axis Calibration.
.TP 7
+.BI Option \*qTransformationMatrix\*q \*q c0 c1 c2 c3 c4 c5 c6 c7 c8 \*q
+Applies the 3x3 transformation matrix defined by c0..c8 in row-major
+order to the device coordinates before passing them on to the X
+server. The coefficients are floating point values, and the
+coordinates are scaled to the 0..1 range before transformed. This
+feature can be used to restrict absolute devices (e.g. touchscreens)
+to specific outputs in multi-head setups. Property: Evdev Coordinate
+Transformation Matrix.
+.TP 7
.B Option \*qMode\*q \*qRelative\*q\fP|\fP\*qAbsolute\*q
Sets the mode of the device if device has absolute axes.
The default value for touchpads is relative, for other absolute.
@@ -196,6 +205,10 @@ driver.
4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable
in-driver axis calibration.
.TP 7
+.BI Evdev Coordinate Transformation Matrix
+9 floating point values, defining the coordinate transformation matrix
+in row-major order.
+.TP 7
.BI Evdev Axis Inversion
2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis.
.TP 7
diff --git a/src/evdev.c b/src/evdev.c
index 0678edf..c21ba0d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -32,6 +32,8 @@
#endif
#include xorg-server.h
+#include math.h
+
#include X11/keysym.h
#include X11/extensions/XI.h
@@ -119,6 +121,7 @@ static Atom prop_calibration = 0;
static Atom prop_swap = 0;
static Atom prop_axis_label = 0;
static Atom prop_btn_label = 0;
+static Atom prop_transform = 0;
#endif
/* All devices the evdev driver has allocated and knows about.
@@ -347,6 +350,35 @@ EvdevQueueButtonClicks(InputInfoPtr pInfo, int button, int
count)
}
}
+static int
+EvdevClip(InputInfoPtr pInfo, float f, int axis)
+{
+EvdevPtr pEvdev = pInfo-private;
+int v;
+
+v = lroundf(f);
+
+if (v pEvdev-absinfo[axis].maximum)
+v = pEvdev-absinfo[axis].maximum;
+else if (v pEvdev-absinfo[axis].minimum)
+v = pEvdev-absinfo[axis].minimum;
+
+return v;
+}
+
+static void
+EvdevTransformAbsolute(InputInfoPtr pInfo, int v[MAX_VALUATORS])
+{
+EvdevPtr pEvdev = pInfo-private;
+float x, y, *t = pEvdev-transform;
+
+x = t[0]*v[0] + t[1]*v[1] + t[2];
+y = t[3]*v[0] + t[4]*v[1] + t[5];
+
+v[0] = EvdevClip(pInfo, x, ABS_X);
+v[1] = EvdevClip(pInfo, y
[announce] xinput calibrator v0.6.1
Dear all, xinput calibrator is a generic touchscreen calibration program for X.Org v0.6.1 is now available at http://www.freedesktop.org/wiki/Software/xinput_calibrator This is a bugfix release, changelog: xinput_calibrator 0.6.1 [2010-03-21] Bug fixes/enhancements: * More robust device detection: non-master device with axis valuators, in absolute mode and at least two calibratable axes. (reported by Sam Lin, Eric Drechsel) * Require libtool in configure.ac * fix miny and maxx printing order for UDEV and HAL (Mario Domenech Goulart) Kind regards, Tias ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xinput 1.5.1
Only one functional change - test-xi2 prints out the event type name as well. All other changes are man page fixes and packaging fixes. Gaetan Nadon (5): .gitignore: use common defaults with custom section # 24239 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 Deploy the new XORG_DEFAULT_OPTIONS #24242 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jeremy Huddleston (1): This is not a GNU project, so declare it foreign. Julien Cristau (1): Add Peter and Red Hat's copyright notices and licenses to COPYING Peter Hutterer (4): man: remove reference to XListInputDevices man: document XI2 options test-xi2: print event type name as well. xinput 1.5.1 Simon Thum (1): Clarify role of set-ptr-feedback git tag: xinput-1.5.1 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.1.tar.bz2 MD5: 82400f0ba63217df9b00d825532cea7d xinput-1.5.1.tar.bz2 SHA1: f8f45486de7d44b3d7274dfd24f988035fe05910 xinput-1.5.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.1.tar.gz MD5: 0463541dc9a38581577318f593b21d14 xinput-1.5.1.tar.gz SHA1: a1c888e869e8c50c9b79779376833d7e26fd4bf6 xinput-1.5.1.tar.gz pgpytW1m65kM6.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
xinput calibrator v0.6.0
Dear all, xinput calibrator is a generic touchscreen calibration program for X.Org v0.6.0 is now available at http://www.freedesktop.org/wiki/Software/xinput_calibrator The project's aim is to supersede all hacked-up driver-specific calibrators out there, and it has already achieved this in large part. Its main features are (more features below): - dynamically recalibrate the mainline evdev driver - output xorg.conf/HAL policy/UDEV rule in case of other driver - have a minimalistic and intuitive GUI With this announcement I would like to ask X packagers to review touchscreen support in their distribution. (see [1] for background information on how the kernel and X server handle them). [1] http://tias.ulyssis.org/calibration/device_support.html In short: if you have a recent kernel and a recent X.org version, then all you lack is a generic calibrator... Some more information: Website: http://www.freedesktop.org/wiki/Software/xinput_calibrator Source: http://github.com/tias/xinput_calibrator Bugs:http://github.com/tias/xinput_calibrator/issues Features: - 2 GUI's: one in X11 (no dependecies), one in GTKMM (nicer), - has --fake option to test it on systems without a touchscreen, - manpage included, - sample .desktop file included, - generic and works for any Xorg driver (uses Xinput protocol), - output the calibration as Xorg.conf, HAL policy and UDEV rule, - support advanced driver options, such as Evdev's dynamic calibration, - option -v to print out verbose debugging information (for buggy devices), - option to feed current calibration on the command line, - can list all calibratable devices - option to select a specific device (eg. when having multiple touchscreens) In the near future mis-click detection will be added, that will prevent a user from ending up with an erroneous calibration. Feel free to contact me with questions. Kind regards, Tias ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Peter Hutterer ha scritto, Il 11/02/2010 00:18: xserver/Xi/xiproperty.c, ProcXChangeDeviceProperty, or if you're using server 1.7 xinput will likely use XIChangeProperty. that's in the same file, but called ProcXIChangeProperty. that again calls into the property handler, for acceleration properties that is one of the AccelSet*Property calls in xserver/dix/ptrveloc.c. for evdev properties, it's EvdevSetProperty in xf86-input-evdev/src/evdev.c. That's likely where the Error is coming from. Can you provide some more detail though, it might be a trivial fix once I can reproduce it. What's the URL for the calibrator program and what property are you trying to set? Hi Peter, thank you for answering. I'm working with Tias on his project http://github.com/tias/xinput_calibrator These settings, and any xinput set-int-prop atmel-ts Evdev Axis Calibration has no effect. --- # export DISPLAY=:0 # xinput_calibrator Calibrating EVDEV driver for atmel-ts current calibration values (from XInput): min_x=150, max_x=3830 and min_y=190, max_y=3830 To make the settings permanent, create add a startup script for your window manager with the following command(s): xinput set-int-prop atmel-ts Evdev Axes Swap 8 1 xinput set-int-prop atmel-ts Evdev Axis Calibration 32 3581 1929 -106 1946 Doing dynamic recalibration: Swapping X and Y axis... Setting new calibration data: 3581, 1929, -106, 1946 -- # xinput --list --short Virtual core pointer id=2[master pointer (3)] Virtual core XTEST pointer id=4[slave pointer (2)] Generic Mouse id=6[slave pointer (2)] Virtual core keyboardid=3[master keyboard (2)] Virtual core XTEST keyboard id=5[slave keyboard (3)] default keyboard id=8[slave keyboard (3)] atmel-tsid=7[floating slave] # xinput --list-props atmel-ts Device 'atmel-ts': Device Enabled (112): 1 Device Accel Profile (220): 0 Device Accel Constant Deceleration (221): 1.00 Device Accel Adaptive Deceleration (223): 1.00 Device Accel Velocity Scaling (224):10.00 Evdev Reopen Attempts (229):10 Evdev Axis Inversion (230): 0, 0 Evdev Axis Calibration (231): 1000, 10, 1000, 10 Evdev Axes Swap (232): 1 Axis Labels (233): Abs X (226), Abs Y (227), Abs Pressure (228) Button Labels (234):Button Unknown (225), Button Unknown (225), Button Unknown (225), Button Wheel U) Evdev Middle Button Emulation (235):2 Evdev Middle Button Timeout (236): 50 Evdev Wheel Emulation (237):0 Evdev Wheel Emulation Axes (238): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (239):10 Evdev Wheel Emulation Timeout (240):200 Evdev Wheel Emulation Button (241): 4 Evdev Drag Lock Buttons (242): 0 Cheers -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party certified consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput settings ignored
Peter Hutterer ha scritto, Il 11/02/2010 00:26: On Wed, Feb 10, 2010 at 05:35:52PM +0100, Marco Cavallini wrote: Hi I am facing to a weird behaviour with my ARM based touchscreen device, xinput settings ignored and looks like I have a parallel input device. X.Org X Server 1.7.4 # cat /dev/input/touchscreen0 if I touch the screen I can see chars If I start xorg with xinit I can see the graphic application (xterm) and the cursor moves when I touch the screen. Cursor movements are not calibrated and axes are swapped. # cat /etc/X11/xorg.conf ... Section InputDevice Identifier atmel-ts Driver evdev Option SwapAxes 1 Option Device /dev/input/touchscreen0 EndSection ... Can I assume that the touchscreen talks the event API? because if not, some interesting behaviour can be expected. Now, the weird stuff: If I do xinput set-int-prop atmel-ts Device Enabled 8 0 the command xinput test atmel-ts doesn't return any coordinate and any event, but the cursor moves on the screen. If I enable the device xinput set-int-prop atmel-ts Device Enabled 8 1 the command xinput test atmel-ts works, and the cursor has the same behaviour (not cailbrable) May these info give you any idea about what's happening? Any hint will be appreciated. have you disabled hotplugging? chances are the device is added twice, once as part of the xorg.conf, once through HAL. if you disable the xorg.conf device, the other one will happily keep sending coordinates. Hi Peter, I tred removing the touchscreen from xinit.org Results are: 1. touchscreen is still working 2. xinput --list --short no longer detect the touchscreen device 3. and of course xinput-calibrator does not start I'm quite puzzled, why touchscreen is still working? How could I disable the current touch events and replace it with the one defined in xorg.conf? Option Device /dev/input/touchscreen0 TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput settings ignored
Peter Hutterer ha scritto, Il 11/02/2010 00:26: On Wed, Feb 10, 2010 at 05:35:52PM +0100, Marco Cavallini wrote: Hi I am facing to a weird behaviour with my ARM based touchscreen device, xinput settings ignored and looks like I have a parallel input device. X.Org X Server 1.7.4 # cat /dev/input/touchscreen0 if I touch the screen I can see chars If I start xorg with xinit I can see the graphic application (xterm) and the cursor moves when I touch the screen. Cursor movements are not calibrated and axes are swapped. # cat /etc/X11/xorg.conf ... Section InputDevice Identifier atmel-ts Driver evdev Option SwapAxes 1 Option Device /dev/input/touchscreen0 EndSection ... Can I assume that the touchscreen talks the event API? because if not, some interesting behaviour can be expected. Now, the weird stuff: If I do xinput set-int-prop atmel-ts Device Enabled 8 0 the command xinput test atmel-ts doesn't return any coordinate and any event, but the cursor moves on the screen. If I enable the device xinput set-int-prop atmel-ts Device Enabled 8 1 the command xinput test atmel-ts works, and the cursor has the same behaviour (not cailbrable) May these info give you any idea about what's happening? Any hint will be appreciated. have you disabled hotplugging? chances are the device is added twice, once as part of the xorg.conf, once through HAL. if you disable the xorg.conf device, the other one will happily keep sending coordinates. Cheers, Peter, you was right! The problem was caused by double InputDevice definition in xorg.conf Removing the mouse device xinput calibrator work smoothly. Thank you all. Section InputDevice Identifier atmel-ts Driver evdev Option SwapAxes 1 Option Device /dev/input/touchscreen0 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option CorePointer EndSection Section ServerLayout Identifier Layout Screen fbscreen #InputDevice Generic Mouse InputDevice atmel-ts CorePointer EndSection Cheers -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party certified consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Peter Hutterer ha scritto, Il 11/02/2010 00:18: On Wed, Feb 10, 2010 at 05:28:57PM +0100, Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 13:29: Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 11:47: Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. Simon, If I see the following properties, should I be able to set an of them? Yeah you should. But it's important to get the value and type right. Citing from evdev-properties.h: /* Run-time calibration */ /* CARD32, 4 values [minx, maxx, miny, maxy], or no values for unset */ #define EVDEV_PROP_CALIBRATION Evdev Axis Calibration (you should have this file if you compiled evdev or have a *-dev package) You ought to be getting errors if it doesn't work: si...@simons ~ $ xinput --set-prop 6 Device Accel Constant Deceleration -1 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 139 (XInputExtension) Minor opcode of failed request: 57 () Value in failed request: 0xf3 Serial number of failed request: 17 Current serial number in output stream: 18 My calls are successfull and I get back any error. I still have no effects on XChangeDeviceProperty calls. Anybody could point me where to continue digging? For instance, where is XChangeDeviceProperty? xserver/Xi/xiproperty.c, ProcXChangeDeviceProperty, or if you're using server 1.7 xinput will likely use XIChangeProperty. that's in the same file, but called ProcXIChangeProperty. that again calls into the property handler, for acceleration properties that is one of the AccelSet*Property calls in xserver/dix/ptrveloc.c. for evdev properties, it's EvdevSetProperty in xf86-input-evdev/src/evdev.c. That's likely where the Error is coming from. Can you provide some more detail though, it might be a trivial fix once I can reproduce it. What's the URL for the calibrator program and what property are you trying to set? How it manage the raw coordinates coming from /dev/input/touchscreen0 ? not quite sure what you mean there. Cheers, Peter Solved Peter, you was right! The problem was caused by double InputDevice definition in xorg.conf Removing the mouse device xinput calibrator work smoothly. Thank you all. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Simon Thum ha scritto, Il 27/01/2010 13:29: Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 11:47: Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. Simon, If I see the following properties, should I be able to set an of them? Yeah you should. But it's important to get the value and type right. Citing from evdev-properties.h: /* Run-time calibration */ /* CARD32, 4 values [minx, maxx, miny, maxy], or no values for unset */ #define EVDEV_PROP_CALIBRATION Evdev Axis Calibration (you should have this file if you compiled evdev or have a *-dev package) You ought to be getting errors if it doesn't work: si...@simons ~ $ xinput --set-prop 6 Device Accel Constant Deceleration -1 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 139 (XInputExtension) Minor opcode of failed request: 57 () Value in failed request: 0xf3 Serial number of failed request: 17 Current serial number in output stream: 18 My calls are successfull and I get back any error. I still have no effects on XChangeDeviceProperty calls. Anybody could point me where to continue digging? For instance, where is XChangeDeviceProperty? How it manage the raw coordinates coming from /dev/input/touchscreen0 ? TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xinput settings ignored
Hi I am facing to a weird behaviour with my ARM based touchscreen device, xinput settings ignored and looks like I have a parallel input device. X.Org X Server 1.7.4 # cat /dev/input/touchscreen0 if I touch the screen I can see chars If I start xorg with xinit I can see the graphic application (xterm) and the cursor moves when I touch the screen. Cursor movements are not calibrated and axes are swapped. # cat /etc/X11/xorg.conf ... Section InputDevice Identifier atmel-ts Driver evdev Option SwapAxes 1 Option Device /dev/input/touchscreen0 EndSection ... Now, the weird stuff: If I do xinput set-int-prop atmel-ts Device Enabled 8 0 the command xinput test atmel-ts doesn't return any coordinate and any event, but the cursor moves on the screen. If I enable the device xinput set-int-prop atmel-ts Device Enabled 8 1 the command xinput test atmel-ts works, and the cursor has the same behaviour (not cailbrable) May these info give you any idea about what's happening? Any hint will be appreciated. TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
On Wed, Feb 10, 2010 at 05:28:57PM +0100, Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 13:29: Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 11:47: Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. Simon, If I see the following properties, should I be able to set an of them? Yeah you should. But it's important to get the value and type right. Citing from evdev-properties.h: /* Run-time calibration */ /* CARD32, 4 values [minx, maxx, miny, maxy], or no values for unset */ #define EVDEV_PROP_CALIBRATION Evdev Axis Calibration (you should have this file if you compiled evdev or have a *-dev package) You ought to be getting errors if it doesn't work: si...@simons ~ $ xinput --set-prop 6 Device Accel Constant Deceleration -1 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 139 (XInputExtension) Minor opcode of failed request: 57 () Value in failed request: 0xf3 Serial number of failed request: 17 Current serial number in output stream: 18 My calls are successfull and I get back any error. I still have no effects on XChangeDeviceProperty calls. Anybody could point me where to continue digging? For instance, where is XChangeDeviceProperty? xserver/Xi/xiproperty.c, ProcXChangeDeviceProperty, or if you're using server 1.7 xinput will likely use XIChangeProperty. that's in the same file, but called ProcXIChangeProperty. that again calls into the property handler, for acceleration properties that is one of the AccelSet*Property calls in xserver/dix/ptrveloc.c. for evdev properties, it's EvdevSetProperty in xf86-input-evdev/src/evdev.c. That's likely where the Error is coming from. Can you provide some more detail though, it might be a trivial fix once I can reproduce it. What's the URL for the calibrator program and what property are you trying to set? How it manage the raw coordinates coming from /dev/input/touchscreen0 ? not quite sure what you mean there. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput settings ignored
On Wed, Feb 10, 2010 at 05:35:52PM +0100, Marco Cavallini wrote: Hi I am facing to a weird behaviour with my ARM based touchscreen device, xinput settings ignored and looks like I have a parallel input device. X.Org X Server 1.7.4 # cat /dev/input/touchscreen0 if I touch the screen I can see chars If I start xorg with xinit I can see the graphic application (xterm) and the cursor moves when I touch the screen. Cursor movements are not calibrated and axes are swapped. # cat /etc/X11/xorg.conf ... Section InputDevice Identifier atmel-ts Driver evdev Option SwapAxes 1 Option Device /dev/input/touchscreen0 EndSection ... Can I assume that the touchscreen talks the event API? because if not, some interesting behaviour can be expected. Now, the weird stuff: If I do xinput set-int-prop atmel-ts Device Enabled 8 0 the command xinput test atmel-ts doesn't return any coordinate and any event, but the cursor moves on the screen. If I enable the device xinput set-int-prop atmel-ts Device Enabled 8 1 the command xinput test atmel-ts works, and the cursor has the same behaviour (not cailbrable) May these info give you any idea about what's happening? Any hint will be appreciated. have you disabled hotplugging? chances are the device is added twice, once as part of the xorg.conf, once through HAL. if you disable the xorg.conf device, the other one will happily keep sending coordinates. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xinput-calibrator XChangeDeviceProperty calls ignored
Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. I wonder who is responsible of touchscreen coords adjustment. Does exist a documentation about the flow beginning from touching the screen up to X cursor moving on the screen? Which are the libraries involved into this operation? TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. I wonder who is responsible of touchscreen coords adjustment. The driver, generally. There exists some server code but AFAIK it's dead. Does exist a documentation about the flow beginning from touching the screen up to X cursor moving on the screen? Which are the libraries involved into this operation? I think tihs is a good starter: http://wiki.x.org/wiki/DeveloperStart ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Simon Thum ha scritto, Il 27/01/2010 11:47: Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. Simon, If I see the following properties, should I be able to set an of them? I ask because I get no effect. # xinput --list-props atmel-ts Device 'atmel-ts': Device Enabled (112): 1 Device Accel Profile (220): 0 Device Accel Constant Deceleration (221): 1.00 Device Accel Adaptive Deceleration (223): 1.00 Device Accel Velocity Scaling (224):10.00 Evdev Reopen Attempts (229):10 Evdev Axis Inversion (230): 0, 0 Evdev Axis Calibration (231): no items Evdev Axes Swap (232): 1 Axis Labels (233): Abs X (226), Abs Y (227), Abs Pressure (228) Button Labels (234):Button Unknown (225), Button Unknown (225), Button Unknown (225), Button Wheel U) Evdev Middle Button Emulation (235):2 Evdev Middle Button Timeout (236): 50 Evdev Wheel Emulation (237):0 Evdev Wheel Emulation Axes (238): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (239):10 Evdev Wheel Emulation Timeout (240):200 Evdev Wheel Emulation Button (241): 4 Evdev Drag Lock Buttons (242): 0 TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput-calibrator XChangeDeviceProperty calls ignored
Marco Cavallini wrote: Simon Thum ha scritto, Il 27/01/2010 11:47: Marco Cavallini wrote: Hi, I'm testing and debugging xinput-calibrator and looks like CalibratorEvdev::do_set_prop - XChangeDeviceProperty calls are ignored by Xorg. Properties may reject attempts to change their value (to specific values). Also, if the properties don't exist before, you may be creating them but they don't have any actual meaning. Simon, If I see the following properties, should I be able to set an of them? Yeah you should. But it's important to get the value and type right. Citing from evdev-properties.h: /* Run-time calibration */ /* CARD32, 4 values [minx, maxx, miny, maxy], or no values for unset */ #define EVDEV_PROP_CALIBRATION Evdev Axis Calibration (you should have this file if you compiled evdev or have a *-dev package) You ought to be getting errors if it doesn't work: si...@simons ~ $ xinput --set-prop 6 Device Accel Constant Deceleration -1 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 139 (XInputExtension) Minor opcode of failed request: 57 () Value in failed request: 0xf3 Serial number of failed request: 17 Current serial number in output stream: 18 I ask because I get no effect. # xinput --list-props atmel-ts Device 'atmel-ts': Device Enabled (112): 1 Device Accel Profile (220): 0 Device Accel Constant Deceleration (221): 1.00 Device Accel Adaptive Deceleration (223): 1.00 Device Accel Velocity Scaling (224):10.00 Evdev Reopen Attempts (229):10 Evdev Axis Inversion (230): 0, 0 Evdev Axis Calibration (231): no items Evdev Axes Swap (232): 1 Axis Labels (233): Abs X (226), Abs Y (227), Abs Pressure (228) Button Labels (234):Button Unknown (225), Button Unknown (225), Button Unknown (225), Button Wheel U) Evdev Middle Button Emulation (235):2 Evdev Middle Button Timeout (236): 50 Evdev Wheel Emulation (237):0 Evdev Wheel Emulation Axes (238): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (239):10 Evdev Wheel Emulation Timeout (240):200 Evdev Wheel Emulation Button (241): 4 Evdev Drag Lock Buttons (242): 0 TIA /marco ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how Can i disable Xinput on Xorg-server-1.7.1
You need Xinput. xkb is required in 1.7. Xsdl isn't expected to work. On Dec 28, 2009, at 01:45, 조원준 wrote: i crosscompiled xorg-server-1.7.1 on ppc architecture. but xkbKeymap is not working. so i crosscompiled xkeyboard-config-1.7 and xkbcomp-1.1.1, too. but Xsdl is not working. i don't know use xkb. so i don't want to use Xinput on xorg-server-1.7.1 but ./configure script is do not support --disable-xinput.. how can i solve this problem,? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
how Can i disable Xinput on Xo rg-server-1.7.1
i crosscompiled xorg-server-1.7.1 on ppc architecture. but xkbKeymap is not working. so i crosscompiled xkeyboard-config-1.7 and xkbcomp-1.1.1, too. but Xsdl is not working. i don't know use xkb. so i don't want to use Xinput on xorg-server-1.7.1 but ./configure script is do not support --disable-xinput.. how can i solve this problem,? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session manager or you prefer a different desktop environment - you're on your own. Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
You're right. We need a Generic Userspace Configuration Kit, which could talk to the Session Hotplug Infrastucture Posting from a mobile, pardon my terseness. ~ C. On Dec 2, 2009 5:09 AM, olafbuddenha...@gmx.net wrote: Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session mana... Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
And thus marks the last time I attempt to be sassy on my Droid. But as I was saying, the Generic Userspace Configuration Kit. If we're going to add a Session Hotplug Infrastructure Tasklet, which is desktop-agnostic, in order to configure the X server across multiple platforms, you're going to need a Generic Userspace Configuration Kit to talk to the kernel, since that's where the devices live. Being desktop-aware has a lot of benefits, mostly in the realm of policy control and convenience, and letting the DE configure things is not as bad as, say, having GNOME-specific code in the server. On Wed, Dec 2, 2009 at 9:34 AM, Corbin Simpson mostawesomed...@gmail.com wrote: You're right. We need a Generic Userspace Configuration Kit, which could talk to the Session Hotplug Infrastucture Posting from a mobile, pardon my terseness. ~ C. On Dec 2, 2009 5:09 AM, olafbuddenha...@gmx.net wrote: Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session mana... Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://... -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
Hi, On Sat, Nov 28, 2009 at 01:25:08AM +0100, olafbuddenha...@gmx.net wrote: On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: If you don't want a session manager or you prefer a different desktop environment - you're on your own. Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... I'm sure both GNOME and KDE would love you for writing one that both had no complaints with, and was perfectly integrated with both. And Xfce. And Moblin. And Maemo. And fvwm2, and fluxbox, and my 'sudo Xorg :0 -noreset | ~/bin/de |'. Looking forward to it! :) Cheers, Daniel pgpWm7vowqlqr.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, 26 Nov 2009 11:45:39 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote: Attached is an attempt of a fix to libXext. There's not a lot of wriggle-room, the APIs are quite restrictive and we can't pass a great deal of information around. Additionally, the library has no way of knowing how many events a given extension has, it's pure guesswork (or compiled into the library). Why can't the library know? Presumably it needs to support all of these extension versions, or it won't actually work at all (and should fail to initialize itself). Is it that the extension version isn't known at this point? -- keith.pack...@intel.com pgpCcoNCmVIi1.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Wed, Dec 02, 2009 at 07:15:57PM -0800, Keith Packard wrote: On Thu, 26 Nov 2009 11:45:39 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote: Attached is an attempt of a fix to libXext. There's not a lot of wriggle-room, the APIs are quite restrictive and we can't pass a great deal of information around. Additionally, the library has no way of knowing how many events a given extension has, it's pure guesswork (or compiled into the library). Why can't the library know? Presumably it needs to support all of these extension versions, or it won't actually work at all (and should fail to initialize itself). Is it that the extension version isn't known at this point? Pretty much, yes. For example, in libXrandr, the path is XRRFindDisplay - XextAddDisplay - XInitExtension - XQueryExtension libXrandr libXext libX11libX11 XextAddDisplay gets the number of events passed in and it's hardcoded. Now, you could probably get around that by changing XRRFindDisplay to issue an XRRQueryVersion before XextAddDisplay and adjusting the number of events based on the returned version. You'd need to patch this into every extension though. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, 3 Dec 2009 13:44:59 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: You'd need to patch this into every extension though. Sure, let's at least fix Xinput then; it's the only one changing the number of events on a regular basis anyway. But, the patch to make Xlib not smash other extension events is a good plan too. -- keith.pack...@intel.com pgpqnQnP7JGXU.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, Nov 26, 2009 at 3:55 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Nov 26, 2009 at 09:34:38AM -0500, Tom Horsley wrote: On Thu, 26 Nov 2009 09:19:52 -0500 Tom Horsley wrote: That might be the very thing! There is even a fedora package for it. I'm off to crank it up and see if I can get it to work they way I want. Thanks! Unfortunately, just like gnome-mouse-properties, there is nothing in this tool that will handle the button mapping or drag lock changes I want :-(. As with much of input, we've been in a transitional phase for the last years to turn from the old static system into a more flexible and dynamic one. X is on the bottom of the stack, so any change needs to be reflected in the upper layers - and they're not necessarily there yet. We're slowly catching up, but not as quick as some would like us and many options are still not exposed - drag lock being one example. So here's the cardhouse: As you said, the single xorg.conf file isn't really suited to evdev (or the other way round). The input system is now aimed at per-device, per-session (runtime) configuration. Static configuration is possible, but discouraged. You can dop keys into the HAL configuration, but that'll go away eventually with udev. The best proposal for static configuration were Dan's xorg.conf.d patches but I don't know how much they have progressed in the last months. Maybe Dan can comment on that? Just finished it yesterday (been too busy), and it seems to work correctly. I'll post it shortly. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
Peter Hutterer wrote: On Thu, Nov 26, 2009 at 01:43:25PM -0500, Nathan Kidd wrote: Either approach fixes the WireToEvent case when considering events being generated by the server, but I don't think there's anything that can be done about the EventToWire (SendEvent request) case. Your choice is to use the wrong EventToWire function for either the overlapping extension events, or the following extension events. The former is preferred I think since it will only break very new code (using new events). I think EvToWire should match WireToEv. If a client is trying to send an event that the server doesn't know about then that's a bug in the client anyway. I don't really see a way out to prevent a client from doing this in a safe manner. Agreed. This is another reason that an (event-using) extension *must* provide a QueryVersion type request or otherwise a mechanism to determine how many events the server supports. My quick grepping over *proto suggests that XKB is the only current extension which doesn't seem to provide such a mechanism. But it falls into the special case of still using just the one event it was first published with. +if (XEGetWireToEvent (dpy, j) != _XUnknownWireEvent) +break; + XESetWireToEvent (dpy, j, hooks-wire_to_event); XESetEventToWire (dpy, j, hooks-event_to_wire); } This only works in one case - if the higher one is initialized first. It fails the other case. Given two extensions - base 80 + 20 and base 90 + 5. If extension 1 registers first, range [80,100] would be occupied and cannot be taken by the second extension. The server would still send events for the second extension and they'd be processed by the wrong library extension. Ah, doh. Yes, my patch totally missed the 2nd case. Yours looks good! -Nathan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, Nov 26, 2009 at 11:45:39 +1000, Peter Hutterer wrote:
@@ -117,10 +118,51 @@ XExtDisplayInfo *XextAddDisplay (
*/
if (dpyinfo-codes) {
int i, j;
+ int idx = dpyinfo-codes-first_event 0x3f;
+
+
+ /* Xlib extensions use compiled in event numbers. A new library
+ * against an older server may thus expect a different (higher)
+ * number of events than the server will send. We have no way of
+ * knowing the number of events for an extension, the server won't
+ * tell us.
+ *
+ * Depending on the extension initialization order, this smashes the
+ * event_vec[type] for anything after the extension with the
+ * different number of events.
+ *
+ * e.g. server with inputproto 1.3 expects 15 events, libXi with
+ * inputproto 2.0 expects 17 events.
+ * base code is 80, events [80,96] are handled by libXi. events [95,
+ * 96] belong to the next extension already though.
+ * This requires XI to be initialized after the extension occupying
+ * the next range of event codes.
+ *
+ * To avoid this, we have a zeroed out array of extension handlers.
+ * If an extension handler for an event type is already set, and the
+ * previous event code (before base_code) is the same extension, we
+ * have the nevents conflict. Unset all those handlers and allow
+ * overwriting them with the new handlers.
+ *
+ * If a handler for a (base + n) event is already set, stop
+ * registering this extension for the event codes.
there's some whitespace issues here...
+ *
+ * event_codes are subtracted by 64 since we don't need to worry
+ * about core.
+ */
+
+ if (idx ext_handlers[idx - 1] == ext_handlers[idx]) {
+ for (i = idx; i idx + nevents; i++)
+ if (ext_handlers[idx - 1] == ext_handlers[i])
+ ext_handlers[i] = 0;
+ }
Shouldn't this loop actually look like:
for (i = idx; i 64; i++)
if (ext_handlers[idx - 1] == ext_handlers[i])
ext_handlers[i] = 0;
else
break;
Otherwise if extension1 registers events base to base+10, then
extension2 comes and registers events base+5 to base+7, there'll still
be some wrong values for base+8 to base+10, and extension3 will leave
them alone.
- for (i = 0, j = dpyinfo-codes-first_event; i nevents; i++, j++) {
+ for (i = 0, j = dpyinfo-codes-first_event; i nevents; i++, j++,
idx++) {
+ if (ext_handlers[idx]) /* don't smash the following extension */
+ break;
XESetWireToEvent (dpy, j, hooks-wire_to_event);
XESetEventToWire (dpy, j, hooks-event_to_wire);
+ ext_handlers[idx] = dpyinfo-codes-first_event 0x3f;
}
/* register extension for XGE */
Cheers,
Julien
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
I currently have my new fedora 12 system with no xorg.conf and a script that runs when I login to execute xinput commands to setup my trackball for draglock. This scheme falls apart when I switch my KVM switch to another system. The mouse is unplugged and the xinput settings are lost. The information (if you can call it that) on how I might correct this is both spotty and contradictory. The whole universe seems to have decided that xorg.conf files are the spawn of the devil, so I shouldn't use one of those to fix it (and indeed, the xorg.conf man page seems to indicate that I must use the evdev device number, which I have no way of predicting, to select the device). I find a lot of notes in various places saying what I really need is a hal .fdi policy file, but determining what to put in such a file is more problematic. And, of course, just like xorg.conf, such a policy file would be a system wide setting, not a per-user setting for mouse behavior which should clearly be a user preference. Then there is the fact that I can also find mailing list entries that say hal is oh so 20th century and is on the way out to be replaced by something better (where better apparently means even fewer people understand it :-). Is udev the thing to use instead of hal? If so, that is another system wide setting and another cryptic file I don't know how to write :-). I see that I get dbus system messages when I plug or unplug a mouse or keyboard. Is the grand plan to have a per user daemon listening for these and re-applying xinput settings when they show up? Does this daemon exist already and I just don't know its name? Do we really need yet another daemon? How long before linux runs out of PIDs? :-). Where does a poor linux user who just wants his trackball to be useful with one hand go to figure out what he is supposed to do? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, Nov 26, 2009 at 07:14:16 -0500, Tom Horsley wrote: I see that I get dbus system messages when I plug or unplug a mouse or keyboard. Is the grand plan to have a per user daemon listening for these and re-applying xinput settings when they show up? Does this daemon exist already and I just don't know its name? Do we really need yet another daemon? How long before linux runs out of PIDs? :-). AFAIK that daemon exists and is called gnome-settings-daemon. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, Nov 26, 2009 at 1:33 PM, Julien Cristau jcris...@debian.org wrote: On Thu, Nov 26, 2009 at 07:14:16 -0500, Tom Horsley wrote: I see that I get dbus system messages when I plug or unplug a mouse or keyboard. Is the grand plan to have a per user daemon listening for these and re-applying xinput settings when they show up? Does this daemon exist already and I just don't know its name? Do we really need yet another daemon? How long before linux runs out of PIDs? :-). AFAIK that daemon exists and is called gnome-settings-daemon. Erm... and on system where gnome is not installed? -- Luciano Montanaro Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, 26 Nov 2009 13:33:12 +0100 Julien Cristau wrote: AFAIK that daemon exists and is called gnome-settings-daemon. It is running, but I have no idea how to induce it to apply my draglock settings when the trackball is hot plugged. There is a gnome-mouse-properties tool which allows you to configure a fantastically limited subset of all the things you can do to a mouse. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, Nov 26, 2009 at 08:20:35AM -0500, Tom Horsley wrote: On Thu, 26 Nov 2009 13:33:12 +0100 Julien Cristau wrote: AFAIK that daemon exists and is called gnome-settings-daemon. It is running, but I have no idea how to induce it to apply my draglock settings when the trackball is hot plugged. There is a gnome-mouse-properties tool which allows you to configure a fantastically limited subset of all the things you can do to a mouse. And http://live.gnome.org/GPointingDeviceSettings -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, 26 Nov 2009 14:46:33 +0100 Tomasz Torcz wrote: And http://live.gnome.org/GPointingDeviceSettings That might be the very thing! There is even a fedora package for it. I'm off to crank it up and see if I can get it to work they way I want. Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, 26 Nov 2009 09:19:52 -0500 Tom Horsley wrote: That might be the very thing! There is even a fedora package for it. I'm off to crank it up and see if I can get it to work they way I want. Thanks! Unfortunately, just like gnome-mouse-properties, there is nothing in this tool that will handle the button mapping or drag lock changes I want :-(. I wonder if I can make a generic gnome-settings-daemon plugin that will just run user specified scripts on dbus events? Then fancy GUI tools can come later, but at least people could have a way to get things done while waiting for the fancy stuff... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
Peter Hutterer wrote:
On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote:
In the last few years inputproto's number of events (IEVENTS) has jumped
around quite a bit between 15 and 19, which has resulted in the
following issue I've recently became aware of:
...
AIUI, other extensions may be affected as well, not just
Xi. Any newer library extension run against an older server (where the
extension differs in the number of events) would suffer from this issue.
Correct; XInput just got noticed because it's had more development of
late. (The unfair rewards of all your work on Xi :) )
Attached is an attempt of a fix to libXext. There's not a lot of
wriggle-room, the APIs are quite restrictive and we can't pass a great deal
of information around. Additionally, the library has no way of knowing how
many events a given extension has, it's pure guesswork (or compiled into the
library).
The reason not to just use the display's event_vec (attached patches,
your log message reused) is to avoid adding a libX11/libXext version
dependency?
Either approach fixes the WireToEvent case when considering events being
generated by the server, but I don't think there's anything that can be
done about the EventToWire (SendEvent request) case. Your choice is to
use the wrong EventToWire function for either the overlapping extension
events, or the following extension events. The former is preferred I
think since it will only break very new code (using new events).
Currently two unpatched clients could SendEvent new events (that xserver
didn't know about) successfully if they query extensions in the same
order. The patch will break them, but that's the only fallout I can
think of, and it seems necessary.
-Nathan
From 9a723019b4cef32ac5a2f3c2e3aaadef5447f783 Mon Sep 17 00:00:00 2001
From: Nathan Kidd nk...@opentext.com
Date: Thu, 26 Nov 2009 12:29:10 -0500
Subject: [PATCH] Add XEGetWireToEvent()
Used by libXext to tell if an extension lib and xserver
were built with a difference in the number of extension events,
and avoid resulting protocol decoding errors.
Signed-off-by: Nathan Kidd nk...@opentext.com
---
include/X11/Xlibint.h |7 +++
src/InitExt.c | 11 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/include/X11/Xlibint.h b/include/X11/Xlibint.h
index 2acfc76..010e12e 100644
--- a/include/X11/Xlibint.h
+++ b/include/X11/Xlibint.h
@@ -1184,6 +1184,13 @@ extern Bool (*XESetWireToEvent(
Display*, XEvent*, xEvent*
);
+extern Bool (*XEGetWireToEvent(
+Display* /* display */,
+int /* event_number */
+))(
+Display*, XEvent*, xEvent*
+);
+
extern Bool (*XESetWireToEventCookie(
Display* /* display */,
int /* extension */,
diff --git a/src/InitExt.c b/src/InitExt.c
index 0e6c94e..3068159 100644
--- a/src/InitExt.c
+++ b/src/InitExt.c
@@ -253,6 +253,17 @@ WireToEventType XESetWireToEvent(
return (WireToEventType)oldproc;
}
+WireToEventType XEGetWireToEvent(
+ Display *dpy, /* display */
+ int event_number) /* event routine to get */
+{
+ register WireToEventType proc;
+ LockDisplay (dpy);
+ proc = dpy-event_vec[event_number];
+ UnlockDisplay (dpy);
+ return (WireToEventType)proc;
+}
+
typedef Bool (*WireToEventCookieType) (
Display* /* display */,
XGenericEventCookie* /* re */,
--
1.6.0.4
From f0bf7e955509afe8124925e9f930522df3babc5e Mon Sep 17 00:00:00 2001
From: Nathan Kidd nk...@opentext.com
Date: Thu, 26 Nov 2009 11:54:36 -0500
Subject: [PATCH] Don't smash the event_vec if num_events differs between lib and server.
If the library extension thinks there's more events to an extension than the
server actually has, the event_vec for the overlapping range can get
overwritten. This depends on the initialization order of the libraries.
Signed-off-by: Nathan Kidd nk...@opentext.com
---
src/extutil.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/extutil.c b/src/extutil.c
index ac861ea..a1a42f6 100644
--- a/src/extutil.c
+++ b/src/extutil.c
@@ -119,6 +119,26 @@ XExtDisplayInfo *XextAddDisplay (
int i, j;
for (i = 0, j = dpyinfo-codes-first_event; i nevents; i++, j++) {
+/*
+ * Xlib initializes all event vectors to unknown. If the
+ * vector is not unknown it means we would overwrite another
+ * extension's vector. This can happen when the extension lib
+ * is built with more events than the xserver was built with,
+ * so the xserver's space between event_bases is smaller than
+ * the lib expects.
+ *
+ * For receiving events it is safe to simply not set these extra
+ * event vectors since the xserver doesn't know about these
+ * events and thus will never send them.
+ *
+ * For sending events, we can't avoid using the wrong EventToWire
+ * function; either for the (typically) few
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, Nov 26, 2009 at 09:34:38AM -0500, Tom Horsley wrote: On Thu, 26 Nov 2009 09:19:52 -0500 Tom Horsley wrote: That might be the very thing! There is even a fedora package for it. I'm off to crank it up and see if I can get it to work they way I want. Thanks! Unfortunately, just like gnome-mouse-properties, there is nothing in this tool that will handle the button mapping or drag lock changes I want :-(. As with much of input, we've been in a transitional phase for the last years to turn from the old static system into a more flexible and dynamic one. X is on the bottom of the stack, so any change needs to be reflected in the upper layers - and they're not necessarily there yet. We're slowly catching up, but not as quick as some would like us and many options are still not exposed - drag lock being one example. So here's the cardhouse: As you said, the single xorg.conf file isn't really suited to evdev (or the other way round). The input system is now aimed at per-device, per-session (runtime) configuration. Static configuration is possible, but discouraged. You can dop keys into the HAL configuration, but that'll go away eventually with udev. The best proposal for static configuration were Dan's xorg.conf.d patches but I don't know how much they have progressed in the last months. Maybe Dan can comment on that? For said run-time configuration, you need a configuration manager. gnome-settings-daemon along with gnome-control-center is making steps towards it, but there's a bit of inertia, not least because it's designed as a one device config tool, not a per device config tool. And the manpower to work on it is limited. GPointingDeviceSetting is the successor of gsynaptics and aims at per-device configuration. IMO it could do with better integration into the control-center capplets but I haven't looked at it in a while so I might be wrong there. I don't follow KDE or other desktop environments enough to be qualified to commment on what's going on there, I really don't know. If you don't want a session manager or you prefer a different desktop environment - you're on your own. At least until that environment gets the configuration tools required. So for now, not every option exposed by the driver can be enabled conveniently. Once the xorg.conf.d is there, that'll get easier, especially if you don't run a session daemon. If you run a session daemon, you're in for even more fun, since any static configuration may be overridden by the daemon's configuration. e.g. g-s-d supports basic touchpad configuration and that overrides whatever the user sets through HAL/xorg.conf. The key to solving this transitional state is to advance the desktop environment tools to expose more options to the user. I wonder if I can make a generic gnome-settings-daemon plugin that will just run user specified scripts on dbus events? Then fancy GUI tools can come later, but at least people could have a way to get things done while waiting for the fancy stuff... IMO, it's better to go for the fancy GUI tools from the start instead of hacks that allow user-specified scripts to run at random times. I cringe at the thought of bugreports with badly-written shellscripts that conflict with g-s-d settings, they're near impossible to triage. The time it takes you to write this generic plugin is likely the same as it takes you to add the options you need to g-s-d (and control-center). Having done parts of the touchpad tool, I can tell you it's (technically) quite trivial to add new config options. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Fri, 27 Nov 2009, Peter Hutterer wrote: On Thu, Nov 26, 2009 at 09:34:38AM -0500, Tom Horsley wrote: On Thu, 26 Nov 2009 09:19:52 -0500 Tom Horsley wrote: That might be the very thing! There is even a fedora package for it. I'm off to crank it up and see if I can get it to work they way I want. Thanks! Unfortunately, just like gnome-mouse-properties, there is nothing in this tool that will handle the button mapping or drag lock changes I want :-(. As with much of input, we've been in a transitional phase for the last years to turn from the old static system into a more flexible and dynamic one. X is on the bottom of the stack, so any change needs to be reflected in the upper layers - and they're not necessarily there yet. We're slowly catching up, but not as quick as some would like us and many options are still not exposed - drag lock being one example. So here's the cardhouse: As you said, the single xorg.conf file isn't really suited to evdev (or the other way round). The input system is now aimed at per-device, per-session (runtime) configuration. Static configuration is possible, but discouraged. You can dop keys into the HAL configuration, but that'll go away eventually with udev. Does this mean that he should be configuring udev? I've written my own udev files (for usb storage) before; I found it annoying, but possible. [For the record, as far as udev was concerned, I just had to make another file to go in /etc/udev/rules.d/ ]. HTH, - | 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: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Fri, 27 Nov 2009 09:55:22 +1000 Peter Hutterer wrote: I can tell you it's (technically) quite trivial to add new config options. Not when you look at GTK code and see nothing but unintelligible gibberish and macro calls :-). Actually, the dead simplest hack (which I may decide to do) would be a shell script that reads the output from dbus-monitor and switches on the messages it prints to invoke xinput commands :-). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
On Thu, 26 Nov 2009 19:16:27 -0500 Tom Horsley wrote: Actually, the dead simplest hack (which I may decide to do) would be a shell script that reads the output from dbus-monitor and switches on the messages it prints to invoke xinput commands :-). Well, I went and did it, and the horrifying thing is that it works quite well. See this attachment: http://bugzilla-attachments.gnome.org/attachment.cgi?id=148570 to this bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=603103 I now start this script in the background in my .xsession file, and it keeps my drag lock settings around even across hotplug activity. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, Nov 26, 2009 at 01:43:25PM -0500, Nathan Kidd wrote:
Peter Hutterer wrote:
On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote:
In the last few years inputproto's number of events (IEVENTS) has jumped
around quite a bit between 15 and 19, which has resulted in the
following issue I've recently became aware of:
...
AIUI, other extensions may be affected as well, not just
Xi. Any newer library extension run against an older server (where the
extension differs in the number of events) would suffer from this issue.
Correct; XInput just got noticed because it's had more development of
late. (The unfair rewards of all your work on Xi :) )
Attached is an attempt of a fix to libXext. There's not a lot of
wriggle-room, the APIs are quite restrictive and we can't pass a great deal
of information around. Additionally, the library has no way of knowing how
many events a given extension has, it's pure guesswork (or compiled into the
library).
The reason not to just use the display's event_vec (attached patches,
your log message reused) is to avoid adding a libX11/libXext version
dependency?
yes. the patch I sent was actually the third version I implemented, the
former two I dropped for compatibility reasons. Having the solution in one
component only is preferabl. This bug was hard enough to triage as-is, I
don't think we'd want to make that even more complicated.
Especially if it also introduces a new symbol.
Either approach fixes the WireToEvent case when considering events being
generated by the server, but I don't think there's anything that can be
done about the EventToWire (SendEvent request) case. Your choice is to
use the wrong EventToWire function for either the overlapping extension
events, or the following extension events. The former is preferred I
think since it will only break very new code (using new events).
I think EvToWire should match WireToEv. If a client is trying to send an
event that the server doesn't know about then that's a bug in the client
anyway. I don't really see a way out to prevent a client from doing this in
a safe manner.
Currently two unpatched clients could SendEvent new events (that xserver
didn't know about) successfully if they query extensions in the same
order. The patch will break them, but that's the only fallout I can
think of, and it seems necessary.
Right, but trying to send an XI 1.5 event through an XI 1.4 server should
fail anyhow, so...
From 9a723019b4cef32ac5a2f3c2e3aaadef5447f783 Mon Sep 17 00:00:00 2001
From: Nathan Kidd nk...@opentext.com
Date: Thu, 26 Nov 2009 12:29:10 -0500
Subject: [PATCH] Add XEGetWireToEvent()
Used by libXext to tell if an extension lib and xserver
were built with a difference in the number of extension events,
and avoid resulting protocol decoding errors.
Signed-off-by: Nathan Kidd nk...@opentext.com
---
include/X11/Xlibint.h |7 +++
src/InitExt.c | 11 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/include/X11/Xlibint.h b/include/X11/Xlibint.h
index 2acfc76..010e12e 100644
--- a/include/X11/Xlibint.h
+++ b/include/X11/Xlibint.h
@@ -1184,6 +1184,13 @@ extern Bool (*XESetWireToEvent(
Display*, XEvent*, xEvent*
);
+extern Bool (*XEGetWireToEvent(
+Display* /* display */,
+int /* event_number */
+))(
+Display*, XEvent*, xEvent*
+);
+
extern Bool (*XESetWireToEventCookie(
Display* /* display */,
int /* extension */,
diff --git a/src/InitExt.c b/src/InitExt.c
index 0e6c94e..3068159 100644
--- a/src/InitExt.c
+++ b/src/InitExt.c
@@ -253,6 +253,17 @@ WireToEventType XESetWireToEvent(
return (WireToEventType)oldproc;
}
+WireToEventType XEGetWireToEvent(
+ Display *dpy, /* display */
+ int event_number) /* event routine to get */
+{
+ register WireToEventType proc;
+ LockDisplay (dpy);
+ proc = dpy-event_vec[event_number];
+ UnlockDisplay (dpy);
+ return (WireToEventType)proc;
+}
+
typedef Bool (*WireToEventCookieType) (
Display* /* display */,
XGenericEventCookie* /* re */,
--
1.6.0.4
From f0bf7e955509afe8124925e9f930522df3babc5e Mon Sep 17 00:00:00 2001
From: Nathan Kidd nk...@opentext.com
Date: Thu, 26 Nov 2009 11:54:36 -0500
Subject: [PATCH] Don't smash the event_vec if num_events differs between lib
and server.
If the library extension thinks there's more events to an extension than the
server actually has, the event_vec for the overlapping range can get
overwritten. This depends on the initialization order of the libraries.
Signed-off-by: Nathan Kidd nk...@opentext.com
---
src/extutil.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/extutil.c b/src/extutil.c
index ac861ea..a1a42f6 100644
--- a/src/extutil.c
+++ b/src/extutil.c
@@ -119,6 +119,26
Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
Hi, In the last few years inputproto's number of events (IEVENTS) has jumped around quite a bit between 15 and 19, which has resulted in the following issue I've recently became aware of: E.g. 1. xserver is built from inputproto with IEVENTS as 15 (e.g. SLES 10) 15 is statically compiled into xserver. 2. libXi is built some time later with IEVENTS as 17 (e.g. Fedora 11) 17 is statically compiled into libXi. 3. xclient runs on machine with new libXi xclient - QueryExtension(XKEYBOARD) xserver - event base 100 xlib sets event_vec[100] to an xkeyboard WireToEvent function xclient - QueryExtension(XInputExtension) xserver - event base 85 xlib sets event_vec[85 .. 85 + 17] xinput WireToEvent function, i.e. OVERWRITES xkeyboard's WireToEvent proc because xserver only allowed for 15 events between the event bases, since that's all it knew about when it was built. 4. the wrong WireToEvent function get's used on subsequent XKEYBOARD events On standard x.org the results aren't actually that terrible: XKEYBOARD and LBX have their event bases right after XInputExtension so they're the ones that get clobbered. Since nobody uses LBX there's no effect, and XKEYBOARD seems to a) either not be very noticable when it fails b) not be used so often in conjunction with XInputExtension, or c) my googling just can't turn up any complaints. If you juggle around the extensions (e.g. disable in xorg.conf) you can end up clobbering more important/sensitive extension events with far worse results (here XFIXES was after XInputExtension, triggering a segv in most gtk2 applications). Questions: 1. Is this a known issue? (I notice some since-reverted work to add version info to xGetExtensionVersionReq.) 2. Is it not fundamentally a Bad Thing to be changing this statically compiled in number of events? I've worked around this problem by patching old X servers to use IEVENTS = 19 (max value ever shipped in XIproto.h). That way the xserver always allows enough room between event bases, regardless of what type of (currently existing) libXi-using client connects. 3. Does it not makes sense for distro maintainers to apply a similar patch to their older X branches? -Nathan Nathan Kidd Open Text, Connectivity Solutions Group ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Wed, Nov 25, 2009 at 16:42:59 -0500, Nathan Kidd wrote: Hi, In the last few years inputproto's number of events (IEVENTS) has jumped around quite a bit between 15 and 19, which has resulted in the following issue I've recently became aware of: E.g. 1. xserver is built from inputproto with IEVENTS as 15 (e.g. SLES 10) 15 is statically compiled into xserver. 2. libXi is built some time later with IEVENTS as 17 (e.g. Fedora 11) 17 is statically compiled into libXi. 3. xclient runs on machine with new libXi xclient - QueryExtension(XKEYBOARD) xserver - event base 100 xlib sets event_vec[100] to an xkeyboard WireToEvent function xclient - QueryExtension(XInputExtension) xserver - event base 85 xlib sets event_vec[85 .. 85 + 17] xinput WireToEvent function, i.e. OVERWRITES xkeyboard's WireToEvent proc because xserver only allowed for 15 events between the event bases, since that's all it knew about when it was built. 4. the wrong WireToEvent function get's used on subsequent XKEYBOARD events On standard x.org the results aren't actually that terrible: XKEYBOARD and LBX have their event bases right after XInputExtension so they're the ones that get clobbered. Since nobody uses LBX there's no effect, and XKEYBOARD seems to a) either not be very noticable when it fails b) not be used so often in conjunction with XInputExtension, or c) my googling just can't turn up any complaints. If you juggle around the extensions (e.g. disable in xorg.conf) you can end up clobbering more important/sensitive extension events with far worse results (here XFIXES was after XInputExtension, triggering a segv in most gtk2 applications). This sounds like it could be the cause of http://bugs.debian.org/515946 and/or http://bugs.debian.org/515734 which were reported by people using Xserver 1.4 with libXi 1.2, but were never diagnosed properly. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
Julien Cristau wrote: On Wed, Nov 25, 2009 at 16:42:59 -0500, Nathan Kidd wrote: xlib sets event_vec[85 .. 85 + 17] xinput WireToEvent function, i.e. OVERWRITES xkeyboard's WireToEvent proc because xserver only allowed for 15 events between the event bases, since that's all it knew about when it was built. 4. the wrong WireToEvent function get's used on subsequent XKEYBOARD events On standard x.org the results aren't actually that terrible: XKEYBOARD and LBX have their event bases right after XInputExtension so they're the ones that get clobbered. Since nobody uses LBX there's no effect, and XKEYBOARD seems to a) either not be very noticable when it fails b) not be used so often in conjunction with XInputExtension, or c) my googling just can't turn up any complaints. If you juggle around the extensions (e.g. disable in xorg.conf) you can end up clobbering more important/sensitive extension events with far worse results (here XFIXES was after XInputExtension, triggering a segv in most gtk2 applications). This sounds like it could be the cause of http://bugs.debian.org/515946 and/or http://bugs.debian.org/515734 which were reported by people using Xserver 1.4 with libXi 1.2, but were never diagnosed properly. Yes, this is the exact same issue. GDK gets an XFIXESSelectionNotify event that's been decoded by the wrong WireToEvent function, and ends up using a null window id causing a subsequent segv. GDK should check its null pointer, but the root cause is as I described. -Nathan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote:
In the last few years inputproto's number of events (IEVENTS) has jumped
around quite a bit between 15 and 19, which has resulted in the
following issue I've recently became aware of:
E.g.
1. xserver is built from inputproto with IEVENTS as 15 (e.g. SLES 10)
15 is statically compiled into xserver.
2. libXi is built some time later with IEVENTS as 17 (e.g. Fedora 11)
17 is statically compiled into libXi.
3. xclient runs on machine with new libXi
xclient - QueryExtension(XKEYBOARD)
xserver - event base 100
xlib sets event_vec[100] to an xkeyboard WireToEvent function
xclient - QueryExtension(XInputExtension)
xserver - event base 85
xlib sets event_vec[85 .. 85 + 17] xinput WireToEvent function, i.e.
OVERWRITES xkeyboard's WireToEvent proc because xserver only allowed for
15 events between the event bases, since that's all it knew about when
it was built.
4. the wrong WireToEvent function get's used on subsequent XKEYBOARD events
Thanks for the detailed analysis, it helped greatly scoping out a possible
fix for this issue. AIUI, other extensions may be affected as well, not just
Xi. Any newer library extension run against an older server (where the
extension differs in the number of events) would suffer from this issue.
Attached is an attempt of a fix to libXext. There's not a lot of
wriggle-room, the APIs are quite restrictive and we can't pass a great deal
of information around. Additionally, the library has no way of knowing how
many events a given extension has, it's pure guesswork (or compiled into the
library).
I'll let the patch stand as-is, there's a long comment essentially
stating your findings and a description of the fix. A second attachment is a
simple test program to verify the bug and the fix. Run with LD_PRELOAD set
libfakelib.so.
Cheers,
Peter
From ef1abf3fc6a0aa8b47014df078fe551f673142e5 Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Thu, 26 Nov 2009 09:38:31 +1000
Subject: [PATCH] Don't smash the event_vec if num_events differs between lib
and server.
If the library extension thinks there's more events to an extension than the
server actually has, the event_vec for the overlapping range can get
overwritten. This depends on the initialization order of the libraries.
Reported-by: Nathan Kidd
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/extutil.c | 44 +++-
1 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/src/extutil.c b/src/extutil.c
index ac861ea..ff823bd 100644
--- a/src/extutil.c
+++ b/src/extutil.c
@@ -103,6 +103,7 @@ XExtDisplayInfo *XextAddDisplay (
int nevents,
XPointer data)
{
+static unsigned char ext_handlers[64] = {0};
XExtDisplayInfo *dpyinfo;
dpyinfo = (XExtDisplayInfo *) Xmalloc (sizeof (XExtDisplayInfo));
@@ -117,10 +118,51 @@ XExtDisplayInfo *XextAddDisplay (
*/
if (dpyinfo-codes) {
int i, j;
+ int idx = dpyinfo-codes-first_event 0x3f;
+
+
+ /* Xlib extensions use compiled in event numbers. A new library
+* against an older server may thus expect a different (higher)
+* number of events than the server will send. We have no way of
+* knowing the number of events for an extension, the server won't
+* tell us.
+*
+* Depending on the extension initialization order, this smashes the
+* event_vec[type] for anything after the extension with the
+* different number of events.
+*
+* e.g. server with inputproto 1.3 expects 15 events, libXi with
+* inputproto 2.0 expects 17 events.
+* base code is 80, events [80,96] are handled by libXi. events [95,
+* 96] belong to the next extension already though.
+* This requires XI to be initialized after the extension occupying
+* the next range of event codes.
+*
+* To avoid this, we have a zeroed out array of extension handlers.
+* If an extension handler for an event type is already set, and the
+* previous event code (before base_code) is the same extension, we
+* have the nevents conflict. Unset all those handlers and allow
+* overwriting them with the new handlers.
+ *
+ * If a handler for a (base + n) event is already set, stop
+ * registering this extension for the event codes.
+*
+* event_codes are subtracted by 64 since we don't need to worry
+* about core.
+*/
+
+ if (idx ext_handlers[idx - 1] == ext_handlers[idx]) {
+ for (i = idx; i idx + nevents; i++)
+ if (ext_handlers[idx - 1] == ext_handlers[i])
+ ext_handlers[i] = 0;
+ }
- for (i = 0, j = dpyinfo-codes-first_event; i nevents; i++, j++) {
+ for (i = 0, j = dpyinfo-codes-first_event; i nevents; i++, j++,
idx
[ANNOUNCE] xinput 1.5.0
One rather important change before the final release: --list by default will print out the short format. Other than that, some man page cleanup, and --version now displays the server version as well. Peter Hutterer (3): man: clean up the man page. Clean up --version, don't require a DISPLAY and display the server version too. xinput 1.5.0 Thomas Jaeger (1): Rework 'xinput list' code git tag: xinput-1.5.0 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.0.tar.bz2 MD5: 3e8a5f1faccc8ab00c6190e5a34e0a45 xinput-1.5.0.tar.bz2 SHA1: 02d1ccc83007aa7848b1b024ac64c310303f973e xinput-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.0.tar.gz MD5: 1621839185c0fb5200e67ce5f08c31ac xinput-1.5.0.tar.gz SHA1: 66cc562b6b3eeed2f1e2afa5fa7c35294612ca78 xinput-1.5.0.tar.gz pgpqMjLg3ffX5.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xinput 1.5.0
One rather important change before the final release: --list by default will print out the short format. Other than that, some man page cleanup, and --version now displays the server version as well. Peter Hutterer (3): man: clean up the man page. Clean up --version, don't require a DISPLAY and display the server version too. xinput 1.5.0 Thomas Jaeger (1): Rework 'xinput list' code git tag: xinput-1.5.0 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.0.tar.bz2 MD5: 3e8a5f1faccc8ab00c6190e5a34e0a45 xinput-1.5.0.tar.bz2 SHA1: 02d1ccc83007aa7848b1b024ac64c310303f973e xinput-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.0.tar.gz MD5: 1621839185c0fb5200e67ce5f08c31ac xinput-1.5.0.tar.gz SHA1: 66cc562b6b3eeed2f1e2afa5fa7c35294612ca78 xinput-1.5.0.tar.gz pgpvHfhE94vlo.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xinput 1.4.99.3
Another snapshot for testing.
A new commandline option has been added: --set-prop. This allows for
changing existing properties without having to worry about the format and
type of the property - those are chosen automatically.
Alan Coopersmith (1):
Use __xorgversion__ instead of RCS $Date in man page header/footer
Julien Cristau (3):
Add a format and type argument to the set_prop functions
set-prop: add --type={atom,float,int} and --format={8,16,32} options
Use do_set_prop for set_{atom,float,int}_prop
Peter Hutterer (3):
test_xi2: Print the key repeat flag if it is set.
Require xorg-macros 1.3 for XORG_DEFAULT_OPTIONS.
Bump to 1.4.99.3
git tag: xinput-1.4.99.3
http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.3.tar.bz2
MD5: cc2b98b561b6431bd1e06d13ad2c7b5e xinput-1.4.99.3.tar.bz2
SHA1: 472dc49cf4fe8aabdd16cc410005f48f67d99875 xinput-1.4.99.3.tar.bz2
http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.3.tar.gz
MD5: 58eec938adaad28dcf1ff93481a16381 xinput-1.4.99.3.tar.gz
SHA1: d1930bb60361abcf59357baf9754a09080524a3c xinput-1.4.99.3.tar.gz
pgpVvBbTbhSJO.pgp
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xinput 1.4.99.3
Another snapshot for testing.
A new commandline option has been added: --set-prop. This allows for
changing existing properties without having to worry about the format and
type of the property - those are chosen automatically.
Alan Coopersmith (1):
Use __xorgversion__ instead of RCS $Date in man page header/footer
Julien Cristau (3):
Add a format and type argument to the set_prop functions
set-prop: add --type={atom,float,int} and --format={8,16,32} options
Use do_set_prop for set_{atom,float,int}_prop
Peter Hutterer (3):
test_xi2: Print the key repeat flag if it is set.
Require xorg-macros 1.3 for XORG_DEFAULT_OPTIONS.
Bump to 1.4.99.3
git tag: xinput-1.4.99.3
http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.3.tar.bz2
MD5: cc2b98b561b6431bd1e06d13ad2c7b5e xinput-1.4.99.3.tar.bz2
SHA1: 472dc49cf4fe8aabdd16cc410005f48f67d99875 xinput-1.4.99.3.tar.bz2
http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.3.tar.gz
MD5: 58eec938adaad28dcf1ff93481a16381 xinput-1.4.99.3.tar.gz
SHA1: d1930bb60361abcf59357baf9754a09080524a3c xinput-1.4.99.3.tar.gz
pgpqd5WjZGIgE.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: examples of using xinput?
Excerpts from Tom Horsley's message of Sun Sep 20 09:52:17 +1000 2009: OK, I've been trying to understand the official new way to configure my trackball for draglock and to shuffle buttons around to my liking, and while I can tell from web searches that the xinput tool may indeed be the way to do this, I am left completely bumfuzzled by how the heck I am supposed to use it. The man page is utterly cryptic and many hours of web searches have turned up zero examples that might give me a hint. Or if the xinput tool isn't really what I want, what is the tool I want? xinput may be used to configure devices at runtime, yes. It's like a swiss army knife though and while quite universally applicable for this not the best user interface. Ideally, the desktop environments will configure this stuff soon but until then: xinput --set-int-prop device name property name format value value ... you can get the deivce name through xinput --list --short, the property name through xinput --list-props device name. For example the following command turns draglock on the trackstick thingy on for button 4: xinput --set-int-prop TPPS/2 IBM TrackPoint Evdev Drag Lock Buttons 8 4 the format is 8-bit (as described in the man page). if you have xinput from git, it'll guess type and format automatically when you run with --set-prop. Button mapping is currently not handled by a property so it's still xinput --set-button-map device name 1 2 3 4 5... Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: examples of using xinput?
if you have xinput from git, it'll guess type and format automatically when you run with --set-prop. I guess there really is a bug somewhere then, I seemed to try set-prop as described, but I don't get anything like drag lock on fedora rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=524428 I couldn't figure out how to use set-int-prop because I need to pass two values (making button 8 a draglock for button 1), and none of the docs mention that variation. Do I just pass multiple pairs of bitsize int, or is bitsize only specified once, with multiple values like bitsize int int, or does set-int-prop have no way to set multiple values? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: examples of using xinput?
On Sun, Sep 20, 2009 at 08:12:03AM -0400, Tom Horsley wrote: if you have xinput from git, it'll guess type and format automatically when you run with --set-prop. I guess there really is a bug somewhere then, I seemed to try set-prop as described, but I don't get anything like drag lock on fedora rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=524428 I couldn't figure out how to use set-int-prop because I need to pass two values (making button 8 a draglock for button 1), and none of the docs mention that variation. Do I just pass multiple pairs of bitsize int, or is bitsize only specified once, with multiple values like bitsize int int, or does set-int-prop have no way to set multiple values? only specified once as it is valid for all values. so in your case --set-int-prop device prop 8 8 1 should do the trick. or just --set-pop device prop 8 1 Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: examples of using xinput?
On Sun, 20 Sep 2009, Peter Hutterer wrote: Excerpts from Tom Horsley's message of Sun Sep 20 09:52:17 +1000 2009: OK, I've been trying to understand the official new way to configure my trackball for draglock and to shuffle buttons around to my liking, and while I can tell from web searches that the xinput tool may indeed be the way to do this, I am left completely bumfuzzled by how the heck I am supposed to use it. The man page is utterly cryptic and many hours of web searches have turned up zero examples that might give me a hint. Or if the xinput tool isn't really what I want, what is the tool I want? xinput may be used to configure devices at runtime, yes. It's like a swiss army knife though and while quite universally applicable for this not the best user interface. Ideally, the desktop environments will configure this stuff soon but until then: xinput --set-int-prop device name property name format value value As someone who doesn't use a desktop environment, but does use Fedora, I dump my xinput commands into /etc/X11/xinit/xinitrc.d/46-SpaceNavigator-settings.sh ...because I have a SpaceNavigator pointing device. I also have a USB keyboard that keeps dropping out on me, so I have a special scrip tfor configuring that too. HTH, - | 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
examples of using xinput?
OK, I've been trying to understand the official new way to configure my trackball for draglock and to shuffle buttons around to my liking, and while I can tell from web searches that the xinput tool may indeed be the way to do this, I am left completely bumfuzzled by how the heck I am supposed to use it. The man page is utterly cryptic and many hours of web searches have turned up zero examples that might give me a hint. Or if the xinput tool isn't really what I want, what is the tool I want? I warn you, I'll soon be forced to go back to setting AutoAddDevices to false in xorg.conf and doing things the old way, then what are all these improvements for? :-). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xinput 1.4.99.2
Another snapshot for those building mainly from tarballs. Mainly fixes for the ever-moving XI2 API. Benjamin Close (1): Obtain the XInput opcode and check that GenericEvents are actually XI events Peter Hutterer (12): Fix --help output for create-master and remove-master. test_xi2: use %#x alternative printf format. test_xi2: don't map the window before selecting for events. Plug memory leak from XGetAtomName. test_xi2: Update to use cookie events - require libXi 1.2.99.2 test_xi2: Plug memory leak with XGetAtomName. Adjust to new, split-up raw event types. Use XI2 defines for enter/leave modes and detail. test_xi: Print deviceid for enter events too Print XINotifyPassiveGrab detail in enter events too. test-xi2: Update to keycode grabs instead of keysym grabs. Bump to 1.4.99.2 Thomas Jaeger (1): remove-master: document possible return modes in --help git tag: xinput-1.4.99.2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.2.tar.bz2 MD5: 66cb86beeb27c53f7de1bb39b918ec2f xinput-1.4.99.2.tar.bz2 SHA1: c67b11edbf5d195c9733f5acd739ac9e5798dece xinput-1.4.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.2.tar.gz MD5: ab8b1bbd9c9f7ddd2a2e1aaa0f0c928d xinput-1.4.99.2.tar.gz SHA1: aa8db27b25fd83270b05c4766bc5bd4151b92406 xinput-1.4.99.2.tar.gz pgp6BAMy0pKaT.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Update synaptics to XInput 7 ABI
On Mon, Jun 22, 2009 at 01:56:07AM -0400, Ben Gamari wrote: On Fri, Jun 19, 2009 at 04:34:33PM +1000, Peter Hutterer wrote: On Fri, Jun 19, 2009 at 02:01:30AM -0400, Ben Gamari wrote: How about this one (obviously on top of fd939)? Looks good (once someone figures out the button label situation). So getting the labels right is mostly candy now anyway, and getting them for the ones after 7 is something we can worry about in the future, but don't have to worry about right now. Oops, it seems I messed up. When I tested your patches it turned out that I wasn't actually testing your patches. It seems that providing a label of 0 causes gnome-settings-daemon to crash with the following backtrace, [...] Changing the third argument of the InitPointerDeviceStruct() call in synaptics' DeviceInit() from SYN_MAX_BUTTONS to 7 avoids the crash. Changing it then to 8 (as was done in the case of the above backtrace) triggers the crash. Not really sure what to make of this. Let me know what you think. Thanks, server bug, uncovered by 280b7f92d729ec910ffa3d18dce7bbc215be7a3c. http://bugs.freedesktop.org/show_bug.cgi?id=22392 Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Update synaptics to XInput 7 ABI
On Fri, Jun 19, 2009 at 04:34:33PM +1000, Peter Hutterer wrote: On Fri, Jun 19, 2009 at 02:01:30AM -0400, Ben Gamari wrote: How about this one (obviously on top of fd939)? Looks good (once someone figures out the button label situation). So getting the labels right is mostly candy now anyway, and getting them for the ones after 7 is something we can worry about in the future, but don't have to worry about right now. Cool, so will you be committing your patch? - Ben ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Update synaptics to XInput 7 ABI
On Sun, Jun 21, 2009 at 03:38:15PM -0400, Ben Gamari wrote: On Fri, Jun 19, 2009 at 04:34:33PM +1000, Peter Hutterer wrote: On Fri, Jun 19, 2009 at 02:01:30AM -0400, Ben Gamari wrote: How about this one (obviously on top of fd939)? Looks good (once someone figures out the button label situation). So getting the labels right is mostly candy now anyway, and getting them for the ones after 7 is something we can worry about in the future, but don't have to worry about right now. Cool, so will you be committing your patch? done. sorry for the delay. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xinput 1.4.99.1
xinput master never got bumped, so here's the list of changes since the 1.4.1 branching and a current snapshot for those needing it to play with the new XI2 bits. This is merely a snapshot of the current state, do not expect this to be API compatible to libXi for longer than a New York Second. Cheers, Peter Benjamin Close (2): Error out when more than one instance of a name exists Remove superfluous dev assignment. Julien Cristau (2): Factorize atom parsing in its own function xinput: add set-prop command Peter Hutterer (50): Clean up xinput.h a bit. Rip HAVE_XI2 conditional functionality out. add xi2_find_device_id Change is_xinput_present() to xinput_version(). Update to new XI2 requests and sanitize the check for XI2 in configure. If XI2 is available, list devices through XIQueryDevice. Add test_xi2 for xi2 testing. Print DeviceChanged events. Print out hierarchy events Change event registration a bit, using SetBit instead. Register for raw events Print enter/leave and focus events. Fix 64 bit issues with set-int-prop. fix 64 bit issues with set-int-prop and list-props. Fix set-float-prop on 64-bit architectures. replace BYTE with an unsigned char. Actually print event_y when trying to print event_y in Enter/Leave events. Print event/root x/y on device events. Register for exposure events and block until we're mapped. Add a hunk to test XI2 sync'd grabs. XSync the display before jumping in the grab code. If there's multiple null-terminated strings in the property, print all. The float_atom should actually be an Atom If there's multiple null-terminated strings in the property, print all. Create the float property if it doesn't exist. Clean up xinput.h a bit Remove one more unnecessary ifdef. XCloseDisplay when we're done. Get the XIDeviceInfo instead of just the id. Add support for XI2 property requests. Clean up xinput.h a bit XCloseDisplay when we're done. update test_xi2 with a few more tests. Update to new inputproto defines. Update to new inputproto and libXi naming conventions. Print floating slaves in XI2 list mode. Deal with None atoms. Print None properties in XI2 mode too. Print empty properties as no items. Print empty XI2 properties as no items Print empty properties as no items. xi2 test: add two missing breaks. Fix build errors introduced by inputproto 1.9.99.11. Use the XI2 class defines for listing device classes in XI2 mode. Print the sourceid when listing device classes. Print button state when listing XI2 devices. Print button and valuator labels when listing a device. Print the valuator value for absolute axes. Require inputproto 1.9.99.12 Bump to 1.4.99.1 Simon Thum (2): xinput: mention set-float-prop in manpage xinput: include device type in device list Thomas Jaeger (4): test-xi2: fix modifiers for XIGrabButton call test-xi2: Use standard macros instead of BitIsOn/SetBit test-xi2: Report correct event coordinates reattach: Default to return to VCP/VCK when returnMode is AttachToMaster git tag: xinput-1.4.99.1 http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.1.tar.bz2 MD5: 4b255aafae9ddd59e10292f8bac5504e xinput-1.4.99.1.tar.bz2 SHA1: df36328517c72f68fa58cb5b454a9a4bcc5e5356 xinput-1.4.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.4.99.1.tar.gz MD5: 77bff7cb31f2c81853b4cfb3b16eda7e xinput-1.4.99.1.tar.gz SHA1: 6afabc257df680b9c1822ac885630add15b59abd xinput-1.4.99.1.tar.gz pgp2yRn8ogfg4.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: the problem of xinput
On Fri, Jun 19, 2009 at 10:56:17PM +0800, liming cheng wrote: By accident I found two cursor on the screen,I didn'n know when the second cursor come out.But I cann't control it.I was told to use the xinput commod xinput --list --short xinput --create-master foobar xinput --reattach MyMouse foobar pointer xinput --reattach MyKeyboard foobar keyboard I have update my xinput from git:// anongit.freedesktop.org/git/xorg/app/xinput,but I couldn't use --create-master and --reattach options,either,why?? did you have the PKG_CONFIG_PATH set to the installation of libXi from master when you compiled xinput? if it picks up your system libXi, then it won't build with the XI2 bits. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
