Re: Input device configuration plans (was re: xf86-input-synaptics 1.0.99.3)
On Thu, Mar 5, 2009 at 4:07 AM, Peter Hutterer wrote: > On Thu, Mar 05, 2009 at 09:15:32AM +, Colin Guthrie wrote: >> > If synclient/gsynaptics are insufficient, I'd patch the driver. >> > fdi files as configuration were always frowned upon and were mostly used >> > because of a lack of alternatives. >> >> Hmm, strange. I was kinda basing my approach on the comments in the >> Fedora synaptic package's FDI file... > > we need to leave that in for a bit longer until we have (gui) tools to > configure and manage settings at runtime. > >> Isn't inconcistency worse than breaking this one approach here. At >> present only a subset of input drivers are configurable in xorg.conf and >> others are not. If I have to explain to a user that they cannot set they >> keyboard locale in xorg.conf but they can configure their synaptics >> options, is this not a more confusing response to someone? They feel >> like you just have to "know" in order to know! >> >> This is a genuinely open question by me, I'm not trying to put a >> particular slant on it or push it one way, I'm just a bit confused now >> as to why some drivers work one way and others another. >> >> Perhaps I'm just not seeing the strategy here... what is the intended >> plan moving forward? Push more stuff into hal or less? Or perhaps make >> hal+conf parsing augment each other rather than hal overriding the conf? >> Whatever the plan is, I'd argue consistency should be a key consideration. > > I admit, much of the input stuff so far was fire-fighting, more so than a > grand strategy. It's one of these times when things get worse before they get > better. FWIW, I think we're on the verge of the "getting better" part though. Allow me to toss out the hotplugged xorg.conf patch I made previously. http://lists.freedesktop.org/archives/xorg/2008-December/041188.html While this does not solve all the configuration problems, it does address the xorg.conf consistency Colin's talking about. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Input device configuration plans (was re: xf86-input-synaptics 1.0.99.3)
On Thu, Mar 05, 2009 at 09:15:32AM +, Colin Guthrie wrote: > > If synclient/gsynaptics are insufficient, I'd patch the driver. > > fdi files as configuration were always frowned upon and were mostly used > > because of a lack of alternatives. > > Hmm, strange. I was kinda basing my approach on the comments in the > Fedora synaptic package's FDI file... we need to leave that in for a bit longer until we have (gui) tools to configure and manage settings at runtime. > Isn't inconcistency worse than breaking this one approach here. At > present only a subset of input drivers are configurable in xorg.conf and > others are not. If I have to explain to a user that they cannot set they > keyboard locale in xorg.conf but they can configure their synaptics > options, is this not a more confusing response to someone? They feel > like you just have to "know" in order to know! > > This is a genuinely open question by me, I'm not trying to put a > particular slant on it or push it one way, I'm just a bit confused now > as to why some drivers work one way and others another. > > Perhaps I'm just not seeing the strategy here... what is the intended > plan moving forward? Push more stuff into hal or less? Or perhaps make > hal+conf parsing augment each other rather than hal overriding the conf? > Whatever the plan is, I'd argue consistency should be a key consideration. I admit, much of the input stuff so far was fire-fighting, more so than a grand strategy. It's one of these times when things get worse before they get better. FWIW, I think we're on the verge of the "getting better" part though. So my opinion for input configuration: - have the driver choose some useable defaults. - fdi files are for driver selection, and for permanent, device-dependent configuration only. One example for a valid use would be a setting that fixes bugs in the hardware, not user-specific configuration. As a general rule, if the resulting fdi file can't be shared across distros, then it's probably not the right place to put a configuration. - have user-specific settings (tapping, acceleration, button mapping, etc.) through device properties, controlled by a settings daemon (usually provided by the desktop environment). This leaves only one place where we run into issues - the login manager. They have to cook up their own solution and somehow communicate with the DE about best picks. This will be similar to the current keyboard layout selection - which isn't perfect, but can be made good enough to make a user log in. Of these three steps, we have the first two done. The third step is half-done - the mechanisms are there, the programs to use them aren't yet. Then we also have to deal with the inertia of having told people to configure in fdi files what they couldn't yet do in the GUI, etc, those who still have their xorg.conf around, etc. Long-term I want permanent storage in config files gone and instead have a run-time program manage user-specific settings. That is for the 90% part of users anyway. I'm not sure myself yet on the 10% yet that require custom configurations for one reason or another. Cheers, Peter PS: the only reason why synaptics still works fine with the xorg.conf is because it grabs the device. We had to get rid of that for evdev. And of course because hotplugging isn't a major requirement for touchpads. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Peter Hutterer at 05/03/09 02:32 did gyre and gimble: > Thanks, fixed now with 1.0.99.4. A missing #define resulted in the struct > sizes being different in the driver and the server. Quite entertaining. Awesome :) Thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Peter Hutterer at 05/03/09 00:24 did gyre and gimble: > For tapping: > This is a definitive break to 0.15, with the feature being disabled now by > default on most touchpads. There's arguments to both sides, one being that > tapping enabled causes erroneous clicks, especially for those with reduced > dexteriority. The other argument is of course that it's a feature that makes > the touchpad attractive. Members from both groups can be quite vocal, so > either default is wrong in some way. > > I don't care strongly enough either way. Tap has been disabled in the driver > since September now, so I want to stick with it. Subjectively bad but > predictable defaults are better than defaults that change every month. Yes, personally I prefer this as it's not uncommon, even with my awesome dexterity, to accidentally start dragging something I didn't meant etc. But I'm just one opinion in a sea of complainants ;) > For scrolling: > Many devices seem to be going towards multi-touch and for this reason I think > two-finger scrolling is the better default. That's pretty much the only > reason. Yeah I prefer this too after forcing myself to use it and working through a few awkward releases/rcs where the support wasn't perfect. Seems good now. >> B. Configure things in the FDI file, and patch the Xserver to ignore >> synaptics in the same way it currently ignores keyboard and [vm]mouse. >> If the user does not want to use hal then they wire it up themselves - >> they should be canny enough to work out the configuration needed if they >> are configuring their config in this way. >> >> That said, I'm looking for the path of least maintenance too. I think B >> is the "neater" solution, but only if you see this ultimately going into >> the xserver. >> >> So, in short WDYT? > > If synclient/gsynaptics are insufficient, I'd patch the driver. > fdi files as configuration were always frowned upon and were mostly used > because of a lack of alternatives. Hmm, strange. I was kinda basing my approach on the comments in the Fedora synaptic package's FDI file... > Patching the server to ignore synaptics xorg.conf devices will not only > increase maintainance for you (maintaining patches in two different repos, > different behaviour to other distros) Well there are not patches to the synaptic driver, just a custom fdi file (same as the Fedora synaptics package, but with some defaults set. For the latter point, yes, perfectly valid, which is why I was asking here ;) > but also create _a lot_ of complaints > about the xorg.conf devices not working. synaptics is about the only device > where xorg.conf sections have continued to work through the whole input system > rework. Isn't inconcistency worse than breaking this one approach here. At present only a subset of input drivers are configurable in xorg.conf and others are not. If I have to explain to a user that they cannot set they keyboard locale in xorg.conf but they can configure their synaptics options, is this not a more confusing response to someone? They feel like you just have to "know" in order to know! This is a genuinely open question by me, I'm not trying to put a particular slant on it or push it one way, I'm just a bit confused now as to why some drivers work one way and others another. Perhaps I'm just not seeing the strategy here... what is the intended plan moving forward? Push more stuff into hal or less? Or perhaps make hal+conf parsing augment each other rather than hal overriding the conf? Whatever the plan is, I'd argue consistency should be a key consideration. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
On Wed, Mar 04, 2009 at 09:27:34PM +, Colin Guthrie wrote: > 'Twas brillig, and Colin Guthrie at 04/03/09 14:47 did gyre and gimble: > > 'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: > >> 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: > >>> Another snapshot before the release since a number of fixes went into this > >>> one. > >>> > >>> Most notably, syndaemon updated to use device properties by default. And > >>> a fix > >>> that caused synclient with properties to fail on 64-bit machines. > >> Seems this is segv'ing for me :s > >> > >> Confirmed by another user too, (both of us are 64 bit). > >> > >> The device is currently configured in xorg.conf (not via hal yet as per > >> my previous mail), but only has Option SHMConfig on set and nothing more. > >> > >> (II) Synaptics touchpad driver version 1.0.99.3 > >> (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 > >> (**) Option "Device" "/dev/input/event2" > >> (II) SynapticsMouse1: x-axis range 1472 - 5472 > >> (II) SynapticsMouse1: y-axis range 1408 - 4448 > >> (II) SynapticsMouse1: pressure range 0 - 255 > >> (II) SynapticsMouse1: finger width range 0 - 0 > >> (II) SynapticsMouse1: buttons: left right middle double triple > >> (--) SynapticsMouse1 touchpad found > >> (**) SynapticsMouse1: always reports core events > >> > >> Backtrace: > >> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] > >> 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] > >> 2: /lib64/libc.so.6 [0x7fd0ae38dab0] > >> 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] > >> 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] > >> 5: /etc/X11/X [0x491a66] > >> 6: /etc/X11/X(InitInput+0x40) [0x468790] > >> 7: /etc/X11/X(main+0x37a) [0x42ecaa] > >> 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] > >> 9: /etc/X11/X [0x42e179] > >> > >> Fatal server error: > >> Caught signal 11. Server aborting > > > > Forgot to say this is with xserver 1.6 > > Did some digging... turns out reverting this commit fixed it up: > http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=c719553dac875824b2d2a8f7714a89998ab4828d > > As I said I (and my other victim) are both 64 bit, so I suspect the > "funny things" you mention are happening even with this commit :s Thanks, fixed now with 1.0.99.4. A missing #define resulted in the struct sizes being different in the driver and the server. Quite entertaining. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
On Wed, Mar 04, 2009 at 09:16:21AM +, Colin Guthrie wrote: > On a related note here Peter, I'm getting hugely negative feedback on > the default two-finger-scroll and non-tapbutton1 settings. That's not a > problem here but essentially I'm going to have to tweak the defaults or > suffer lynching in the streets! Yeah, I've seen bugreports that complain about these defaults too. For tapping: This is a definitive break to 0.15, with the feature being disabled now by default on most touchpads. There's arguments to both sides, one being that tapping enabled causes erroneous clicks, especially for those with reduced dexteriority. The other argument is of course that it's a feature that makes the touchpad attractive. Members from both groups can be quite vocal, so either default is wrong in some way. I don't care strongly enough either way. Tap has been disabled in the driver since September now, so I want to stick with it. Subjectively bad but predictable defaults are better than defaults that change every month. For scrolling: Many devices seem to be going towards multi-touch and for this reason I think two-finger scrolling is the better default. That's pretty much the only reason. Based on anecdotal evidence, those who are complaining tend to be the ones that know how to configure it to their defaults anyway. > 1. Are you tweaking things in Fedora (can't see anything obvious when I > peak!) No, I don't. I did fix up gsynaptics and synclient though and I'm now telling users that they can tweak it at runtime. IMO this is the best solution. > 2. What would be the recommended way to tweak things? > > I can do one of two things: > A. Patch the synaptics driver. > or > B. Configure things in the FDI file, and patch the Xserver to ignore > synaptics in the same way it currently ignores keyboard and [vm]mouse. > If the user does not want to use hal then they wire it up themselves - > they should be canny enough to work out the configuration needed if they > are configuring their config in this way. > > That said, I'm looking for the path of least maintenance too. I think B > is the "neater" solution, but only if you see this ultimately going into > the xserver. > > So, in short WDYT? If synclient/gsynaptics are insufficient, I'd patch the driver. fdi files as configuration were always frowned upon and were mostly used because of a lack of alternatives. Patching the server to ignore synaptics xorg.conf devices will not only increase maintainance for you (maintaining patches in two different repos, different behaviour to other distros) but also create _a lot_ of complaints about the xorg.conf devices not working. synaptics is about the only device where xorg.conf sections have continued to work through the whole input system rework. Breaking this will create a flood of bugs. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Colin Guthrie at 04/03/09 14:47 did gyre and gimble: > 'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: >> 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: >>> Another snapshot before the release since a number of fixes went into this >>> one. >>> >>> Most notably, syndaemon updated to use device properties by default. And a >>> fix >>> that caused synclient with properties to fail on 64-bit machines. >> Seems this is segv'ing for me :s >> >> Confirmed by another user too, (both of us are 64 bit). >> >> The device is currently configured in xorg.conf (not via hal yet as per >> my previous mail), but only has Option SHMConfig on set and nothing more. >> >> (II) Synaptics touchpad driver version 1.0.99.3 >> (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 >> (**) Option "Device" "/dev/input/event2" >> (II) SynapticsMouse1: x-axis range 1472 - 5472 >> (II) SynapticsMouse1: y-axis range 1408 - 4448 >> (II) SynapticsMouse1: pressure range 0 - 255 >> (II) SynapticsMouse1: finger width range 0 - 0 >> (II) SynapticsMouse1: buttons: left right middle double triple >> (--) SynapticsMouse1 touchpad found >> (**) SynapticsMouse1: always reports core events >> >> Backtrace: >> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] >> 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] >> 2: /lib64/libc.so.6 [0x7fd0ae38dab0] >> 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] >> 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] >> 5: /etc/X11/X [0x491a66] >> 6: /etc/X11/X(InitInput+0x40) [0x468790] >> 7: /etc/X11/X(main+0x37a) [0x42ecaa] >> 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] >> 9: /etc/X11/X [0x42e179] >> >> Fatal server error: >> Caught signal 11. Server aborting > > Forgot to say this is with xserver 1.6 Did some digging... turns out reverting this commit fixed it up: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=c719553dac875824b2d2a8f7714a89998ab4828d As I said I (and my other victim) are both 64 bit, so I suspect the "funny things" you mention are happening even with this commit :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Colin Guthrie at 04/03/09 14:40 did gyre and gimble: > 'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: >> Another snapshot before the release since a number of fixes went into this >> one. >> >> Most notably, syndaemon updated to use device properties by default. And a >> fix >> that caused synclient with properties to fail on 64-bit machines. > > Seems this is segv'ing for me :s > > Confirmed by another user too, (both of us are 64 bit). > > The device is currently configured in xorg.conf (not via hal yet as per > my previous mail), but only has Option SHMConfig on set and nothing more. > > (II) Synaptics touchpad driver version 1.0.99.3 > (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 > (**) Option "Device" "/dev/input/event2" > (II) SynapticsMouse1: x-axis range 1472 - 5472 > (II) SynapticsMouse1: y-axis range 1408 - 4448 > (II) SynapticsMouse1: pressure range 0 - 255 > (II) SynapticsMouse1: finger width range 0 - 0 > (II) SynapticsMouse1: buttons: left right middle double triple > (--) SynapticsMouse1 touchpad found > (**) SynapticsMouse1: always reports core events > > Backtrace: > 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] > 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] > 2: /lib64/libc.so.6 [0x7fd0ae38dab0] > 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] > 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] > 5: /etc/X11/X [0x491a66] > 6: /etc/X11/X(InitInput+0x40) [0x468790] > 7: /etc/X11/X(main+0x37a) [0x42ecaa] > 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] > 9: /etc/X11/X [0x42e179] > > Fatal server error: > Caught signal 11. Server aborting Forgot to say this is with xserver 1.6 Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: > Another snapshot before the release since a number of fixes went into this > one. > > Most notably, syndaemon updated to use device properties by default. And a fix > that caused synclient with properties to fail on 64-bit machines. Seems this is segv'ing for me :s Confirmed by another user too, (both of us are 64 bit). The device is currently configured in xorg.conf (not via hal yet as per my previous mail), but only has Option SHMConfig on set and nothing more. (II) Synaptics touchpad driver version 1.0.99.3 (--) SynapticsMouse1 auto-dev sets device to /dev/input/event2 (**) Option "Device" "/dev/input/event2" (II) SynapticsMouse1: x-axis range 1472 - 5472 (II) SynapticsMouse1: y-axis range 1408 - 4448 (II) SynapticsMouse1: pressure range 0 - 255 (II) SynapticsMouse1: finger width range 0 - 0 (II) SynapticsMouse1: buttons: left right middle double triple (--) SynapticsMouse1 touchpad found (**) SynapticsMouse1: always reports core events Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4eca36] 1: /etc/X11/X(xf86SigHandler+0x3e) [0x480a3e] 2: /lib64/libc.so.6 [0x7fd0ae38dab0] 3: /lib64/libc.so.6(strlen+0x30) [0x7fd0ae3d7710] 4: /etc/X11/X(xf86ActivateDevice+0x6c) [0x4918bc] 5: /etc/X11/X [0x491a66] 6: /etc/X11/X(InitInput+0x40) [0x468790] 7: /etc/X11/X(main+0x37a) [0x42ecaa] 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd0ae37a446] 9: /etc/X11/X [0x42e179] Fatal server error: Caught signal 11. Server aborting -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-synaptics 1.0.99.3
'Twas brillig, and Peter Hutterer at 04/03/09 06:58 did gyre and gimble: > Another snapshot before the release since a number of fixes went into this > one. > > Most notably, syndaemon updated to use device properties by default. And a fix > that caused synclient with properties to fail on 64-bit machines. > > Peter Hutterer (12): > synclient: print an error if we can't find the synaptics device. > syndaemon: fix minor typo in --help output. > syndaemon: remove enable/disable_touchpad(), use toggle_touchpad instead > syndaemon: move shm code into shm_init(). > syndaemon: if we wanted XRECORD, but it failed, exit. > syndaemon: use device properties unless SHM is requested. > syndaemon: disable XRecord by default. > synclient: XCloseDisplay doesn't like NULL-pointers. > syndaemon: needs XI_LIBS to link now. > synclient: don't print driver's package version info. > Don't auto-include xorg-server.h in config.h > Bump to 1.0.99.3 On a related note here Peter, I'm getting hugely negative feedback on the default two-finger-scroll and non-tapbutton1 settings. That's not a problem here but essentially I'm going to have to tweak the defaults or suffer lynching in the streets! So I've a couple questions you can maybe answer for me. 1. Are you tweaking things in Fedora (can't see anything obvious when I peak!) 2. What would be the recommended way to tweak things? I can do one of two things: A. Patch the synaptics driver. or B. Configure things in the FDI file, and patch the Xserver to ignore synaptics in the same way it currently ignores keyboard and [vm]mouse. If the user does not want to use hal then they wire it up themselves - they should be canny enough to work out the configuration needed if they are configuring their config in this way. That said, I'm looking for the path of least maintenance too. I think B is the "neater" solution, but only if you see this ultimately going into the xserver. So, in short WDYT? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
