Created attachment 347513 [details] Xorg.0.log Description of problem: According to this article http://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint#Vertical_Scrolling I've put the necessary lines in /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi I don't get the scrolling even then. This worked on F10 with evdev 2.1 (see bug #476982 where this was solved for F10). Will attach Xorg.0.log and the 10-x11-input.fdi files I have evdev-2.2.1 on F11.
Created attachment 347514 [details] 10-x11-input.fdi
Works for me (Fedora 11 on a X61 thinkpad). Note that you need to restart hal to grok the options. This should show the options (I don't like XAxisMapping): ------------------------------------- [vbraun@x61 ~]$ lshal | grep x11_options input.x11_options.Emulate3Buttons = 'true' (string) input.x11_options.EmulateWheel = 'true' (string) input.x11_options.EmulateWheelButton = '2' (string) input.x11_options.EmulateWheelTimeout = '200' (string) input.x11_options.YAxisMapping = '4 5' (string) ------------------------------------- You might need to fix permissions on the fdi file. I have ------------------------------------- [vbraun@x61 ~]$ ll -Z /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi -rw-r--r--. root root system_u:object_r:usr_t:s0 /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi -------------------------------------
I've restarted hal (as well as the system after the changes to the fdi file. Doesn't have any effect. $ ll -Z /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi -rw-r--r--. root root system_u:object_r:usr_t:s0 /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi $ lshal | grep x11_options $ lshal doesn't recognise the input at all. This worked in F10, so I don't understand what's missing. The .fdi file is the one I've attached.
<match key="info.product" string="TPPS/2 IBM TrackPoint"> should be <match key="info.product" contains="TPPS/2 IBM TrackPoint">
I changed the 'string' to 'contains' but it's still not solved. $ lshal | grep IBM udi = '/org/freedesktop/Hal/devices/pnp_IBM3780' info.product = 'PnP Device (IBM3780)' (string) info.udi = '/org/freedesktop/Hal/devices/pnp_IBM3780' (string) pnp.id = 'IBM3780' (string) info.product = 'IBM Enhanced (101/102-key, PS/2 mouse support)' (string) pnp.description = 'IBM Enhanced (101/102-key, PS/2 mouse support)' (string) info.product = 'TPPS/2 IBM TrackPoint' (string) input.product = 'TPPS/2 IBM TrackPoint' (string) $ lshal | grep x11_options $
I don't quite know. it's probably some little typo somewhere that I can't spot like this. the approach is certainly correct. Copy the whole (original) file into /etc/hal/fdi/policies and remove all but one section (the input.mouse section). then add the x11_options to there, restart hal and check. if that works, modify the match line until it adds the keys. contains does partial matching, so you can have a contains "TrackPoint". see if that works, as I said it looks like there's a hidden typo somewhere. the reason for the copy into /etc is that otherwise your modifications will get overwritten next time hal is updated.
Well surprisingly it works now. I have this in my /usr/share../10-x11-input.fdi: !-- From http://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint#Vertical_Scrolling --> <match key="info.product" contains="TPPS/2 IBM TrackPoint"> <merge key="input.x11_options.EmulateWheel" type="string">true</merge> <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge> <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge> <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge> <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge> <merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge> </match> I tried a few combinations, created a /etc/hal/fdi/policy/ dir and put a file in there which contained this snippet, that worked. Then I removed that file and put the text back in the file in /usr/share (and restarted hal and X) and that works as well. I'm certain I had restarted my system the last time I tried this so even that can't have been a factor. Anyway, can't this behaviour be enabled by default for ThinkPad owners?
no. emulate wheel is rather confusing when you don't know it's active. so activating it by default is not a good idea. user's would see scroll events when they haven't scrolled (because they didn't know the stick did it for them).
(In reply to comment #8) > no. emulate wheel is rather confusing when you don't know it's active. so > activating it by default is not a good idea. user's would see scroll events > when they haven't scrolled (because they didn't know the stick did it for > them). The scroll happens when you press the middle button and apply pressure on the trackpoint. This is the default behaviour on Windows as well. Also, users who use thinkpads arguably know how the trackpoint is to be used ;-)
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
closing as NOTABUG, this was a configuration problem that is now resolved. In Fedora 13, the same can be achieved with an InputClass section in the /etc/xorg.conf.d directory. Please see https://fedoraproject.org/wiki/Input_device_configuration for more details.