Bug 53873

Created attachment 65873 [details]
xorg.configuration as installed by the system

Created attachment 65874 [details]
modification of xorg.conf.d/10-evdev to exclude touchpads

Created attachment 65875 [details]
special xorg.conf ment to make it use the synaptics driver

Created attachment 65876 [details]
log with modified 10-evdev

Created attachment 65877 [details]
log for special "mouseonly" xorg.conf

both of these logs show that the synaptics driver is loaded for the device.

do you see any events at all? try evtes (http://www.freedesktop.org/wiki/Evtest)

xev does not show anything so far; am going to try evtes now...

Do you have a statically linked git?

Created attachment 65894 [details]
synaptic(1).evtest

In deed evtest can not detect any event.

Possibly something to file upstreams at kernel.org because gpm does no more like my mouse via (/dev/ps)aux either.

sounds like a kernel bug, yes.

upstream report: https://bugzilla.kernel.org/show_bug.cgi?id=46301

Created attachment 65979 [details]
configuration that makes the touchpad work

In deed it was a configuration issue!! Just too strange that evtest did report nothing! May there still be a relationship to a (minor) kernel issue?
Why does it no more take the old style configuration posted above (xorg.conf) into account=?

(In reply to comment #13)
> Just too strange that evtest did report nothing!

It appears that synaptics driver still, by defaut, "grabs" input device so that the same event stream does not reach /dev/input/mice, which noone uses anymore... This is what prevents events shpowing up in evtest when it is running in X session.

Dmitry: the synaptics driver grabs to avoid duplicate _synaptics_ devices when users have hotplugging but still leftover xorg.conf InputDevice sections. most of these problems are gone now, but it requires some testing for configuration combinations that no-one ever found the time for.

However, evtest should print a big warning about grabbed devices, its man page and the wiki page I linked to specifically points this out too. Elmar, where did you get evtest from? And I still can't see anything in the configuration that is special?

I have run evtest in runlevel 3 without Xorg (very strange) but did not get any touchpad events (perhaps gpm was running; am going to re-test).

Created attachment 66100 [details]
evtest(2).log

  Strange, I could not reproduce the evtest bug. Perhaps some program was still running from the terminated KDE session last time. 
  However it still may be an issue that the X-Server can lock up all user input if it is not configured correctly. Remember the only way to escape was the power button. Perhaps we should keep the [Ctrl][Alt][F-x] keys working and exclude them from re-mapping (well the can be remapped by loadkeys on text terminals but the X-server should to my mind not do so.) - the same as for the SysRq - keys.

(In reply to comment #17)
> However it still may be an issue that the X-Server can lock up all user input
> if it is not configured correctly. Remember the only way to escape was the
> power button. Perhaps we should keep the [Ctrl][Alt][F-x] keys working and
> exclude them from re-mapping (well the can be remapped by loadkeys on text
> terminals but the X-server should to my mind not do so.) - the same as for the
> SysRq - keys.

uhm, the server has explicit support for VT switching through Ctrl Alt Fx. If that's broken that's a bug. The server doesn't re-map anything here, it compares the incoming keys with the XKB map and then VT switches if the XKB map tells it so (which the default map does).

  See Comment 13, 14: Before it was configured correctly I could only escape by a reboot because the Ctrl-Alt-Fx are processed as normal keystrokes (afaihs no normal keystroke was effective).
  Well, I must confess that I do remap Ctrl and Alt under X: Ctrl to be the innermost modifier, Ctrl to have also on the right instead of Entf/DelRight, Alt to be the second innermost and second most often used modifier and Win to be the outermost for easy mouse operations. This also affects terminal switching on the X terminal vt8. On the console I have changed the terminal switcher from Alt to Window because this is the only one not being used.
  I don`t see it bad that Alt and Ctrl can be re-mapped; however it was sometimes better to have the same key for it. Xorg would have to read the /usr/share/kbd/keympas/i386/xx/xy.map and look for keycode 110 = Alt, alt keycode 106 = Incr Console or so. However all a little bit too complicated for the practice.
  It definitely seems to be a bug that user input can lock up fully (including the Ctrl and Alt and Fx keys). To escape from this we either need to fix the problems that arise from the bad configuration posted above (no I had not remapped that time) or have a SysRq-key for console switching like ALt-Prn-Fx which would be a kernel issue.