weird. the only way this should fail is when the ioctls fail. and that would indicate a kernel issue. Add this section to your xorg.conf.d somewhere:

Section "InputClass"
   Identifier "don't grab synaptics"
   MatchDriver "synaptics"
   Option "Protocol" "event"
EndSection

This is not a permanent fix, it should narrow down where things go wrong though.

Created attachment 98373 [details]
/var/log/Xorg.0.log bad case (event)

Same issue with this added to xorg.conf.d:

Section "InputClass"
   Identifier "don't grab synaptics"
   MatchDriver "synaptics"
   Option "Protocol" "event"
EndSection

Instead of the original error I now get:

 (II) synaptics: ETPS/2 Elantech Touchpad: ignoring touch events for semi-multitouch device
 (--) synaptics: ETPS/2 Elantech Touchpad: x-axis range 0 - 1280 (res 0)
 (--) synaptics: ETPS/2 Elantech Touchpad: y-axis range 0 - 704 (res 0)
 (--) synaptics: ETPS/2 Elantech Touchpad: pressure range 0 - 255
 (--) synaptics: ETPS/2 Elantech Touchpad: finger width range 0 - 15
 (--) synaptics: ETPS/2 Elantech Touchpad: buttons: left right double triple
 (--) synaptics: ETPS/2 Elantech Touchpad: Vendor 0x2 Product 0xe
 (**) Option "CornerCoasting" "false"
 (**) Option "HorizTwoFingerScroll" "false"
 (**) Option "TapButton1" "0"
 (**) Option "TapButton2" "0"
 (**) Option "TapButton3" "0"
 (**) Option "CoastingSpeed" "0"
 (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found
 (**) ETPS/2 Elantech Touchpad: always reports core events
 (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio4/input/input12/event8"
 (II) XINPUT: Adding extended input device "ETPS/2 Elantech Touchpad" (type: TOUCHPAD, id 12)
 (**) synaptics: ETPS/2 Elantech Touchpad: (accel) MinSpeed is now constant deceleration 2.5
 (**) synaptics: ETPS/2 Elantech Touchpad: (accel) MaxSpeed is now 1.75
 (**) synaptics: ETPS/2 Elantech Touchpad: (accel) AccelFactor is now 0.137
 (**) ETPS/2 Elantech Touchpad: (accel) keeping acceleration scheme 1
 (**) ETPS/2 Elantech Touchpad: (accel) acceleration profile 1
 (**) ETPS/2 Elantech Touchpad: (accel) acceleration factor: 2.000
 (**) ETPS/2 Elantech Touchpad: (accel) acceleration threshold: 4
 (WW) synaptics: ETPS/2 Elantech Touchpad: can't grab event device, errno=16
 [dix] couldn't enable device 12
 (EE) Couldn't init device "ETPS/2 Elantech Touchpad"

Something has a kernel grab on the device. Does anything else access the device? check with lsof if there's another process, if not there may be a race where synaptics doesn't close the fd correctly.

If you add Option "GrabEventDevice" "off", does this fix the issue? If so, it's a synaptics bug.

There is no output from "sudo lsof | grep event8" when the issue occurs.

I cannot reproduce the issue with GrabEventDevice off.

Does the touchpad work? The two logs you posted are caused by the same issue - something else has a grab on the device. If that happens in the initial load you get the "unable to detect protocol" issue, if it happens during device enable you get the "can't grab event device, errno=16" error. 16 is EBUSY which is what the kernel returns when some other client has a grab on the fd.

This could be some imbalanced call in the driver but then I'd expect more people to hit this. Could be a race condition between whatever else tries to grab it just at the wrong time, but I don't know what else is running on your box. the GrabEventDevice option would only fix the second error, if it fixes _both_ errors that could mean you have some other synaptics instance running, or there is some imbalanced call. I wonder if you're hitting a race where one server starts up before the other finished?

With either logfile, the touchpad does not work.

I added the GrabEventDevice off Option to the new Section you proposed in Comment 1. In that case the touchpad is always working and I did not look at the logs.

What is maybe unusual about my setup is the combination of gdm and kde.

I think your suspicion that the device is not properly closed during thr restart sounds reasonable. Can't I enable some kernel trace to confirm this?

gdm/kde shouldn't matter too much, unless you're starting a second X server and seeing some race condition there I guess. There is no good way to debug this other than putting ErrorF() statements into the driver and looking at the log but that requires building the driver from git. You can strace the server, but that'll be harder than just building the driver.

I will look into building the driver. This is rather easy with Arch's build system, but I have to install some build dependencies which may require some package upgrades, for example an upgrade to xf86-input-synaptic 1.7.5. Do you think that's ok, or should I try not to change the system?

Err, never mind. My mistake, I can build just fine without upgrading anything.

eventcomm.o: In function `event_query_is_touchpad':
eventcomm.c:(.text+0xee): undefined reference to `xf86ErrorF'

Same with ErrorF. I guess I'll just use xf86IDrvMsg.

Created attachment 99225 [details]
/var/log/Xorg.N.log bad case (event; with debug output)

I added the output "xf86OpenSerial", "xf86CloseSerial" to corresponding function calls, and "grab: $fd", "ungrab: $fd" to ioctl(fd, EVIOCGRAB, [10]) calls.

There is no "ungrab" in the log for the previous session (not attached), which would explain why the device cannot be grabbed yet by the new session. It also explains why this happens only every second time. But I am not sure if output from closing the X session still goes to the log file?

Created attachment 99226 [details]
Xorg.N.log good case (event; with debug output; session preceding 99225)

This is the logfile with debugging information from the session with working touchpad, which precedes the session with not working touchpad. The output "ungrab" is missing:

 EventDeviceOffHook(InputInfoPtr pInfo)
 {
     UninitializeTouch(pInfo);
+    xf86IDrvMsg(pInfo, X_WARNING, "ungrab: %i\n", pInfo->fd);
     SYSCALL(ioctl(pInfo->fd, EVIOCGRAB, (pointer) 0));
 
     return Success;
 }

looks like you attached the same file twice, sorry. And yes, the output goes to the log file, the logfile is simply rotated to Xorg.N.log.old when the next server starts up.

Created attachment 99284 [details] [review]
0001-eventcomm-Drop-requirement-for-a-grab-during-init.patch

This is for synaptics 1.8 and doesn't fix the cause of your bug, but it'll lessen the effect and is generally useful to have anyway. Just figured I'd archive it here too.

patch above posted as ddd8844a47bfa28974e40fc9aec9b17656415a6c

other than that - it's almost 3 years later, I'm hoping/guessing that this bug may be fixed now