Description of problem: fully updated F20 on Surface Pro (1 and 3), Typecover keyboard does not work but mouse does. # cat /dev/hidraw0 #shows data spewing for keyboard for X doesnt interpret it. related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248958
Can you please do (through e.g. using an external usb keyboard): sudo yum install evemu sudo evemu-record The second command will print a list of input devices, can you please see if the typecover is listed there ? If it is listed, please select it and then press a few keys on the cover and see if they generate events.
Also do you know what kind of interface is being used between the typecover and the surface pro ? If it is usb, can you please run: sudo lsusb -vv &> lsusb.log And then attach lsusb.log?
evemu-record shows the typecover but lists it a "UNKNOWN" "/dev/input/event9: Microsoft Surface Type Cover UNKNOWN" I get this when attempting to record that device(9) error: this device is grabbed and I cannot record events
It is indeed USB. See attachment.
Created attachment 932749 [details] lsusb -vv
(In reply to Nicholas Nachefski from comment #3) > evemu-record shows the typecover but lists it a "UNKNOWN" > > "/dev/input/event9: Microsoft Surface Type Cover UNKNOWN" > > > I get this when attempting to record that device(9) > > error: this device is grabbed and I cannot record events Can you try switching to a text-console (ctrl + alt + f2), login there, and then do the "sudo evemu-record" from there? Then the device should not be grabbed, and you should be able to see if it properly generates events for keypresses. Thanks, Hans
So pressing keys on the keyboard itself does not spew any data. However, when i move my finger on the mouse bad (which is attached to the keyboard) it does spew data. pressing the keyboard keys does *not* spew any data.
*pad
Hi, Can you please reboot the machine, and then directly after boot, from a terminal do: dmesg > dmesg.log ls -lR /sys/bus/usb/drivers &> usb-drivers.log And then attach the generated dmesg.log and usb-drivers.log files here ? Thanks, Hans
Created attachment 945808 [details] dmesg output
Created attachment 945809 [details] usb-drivers.log
Created attachment 945811 [details] evemu-record.log On my SP3, *nothing* gets recorded - keyboard and pad both give nothing.
Hi Jerry, Can you please do the following as root: cd /sys/bus/usb/drivers/usbhid echo '1-3:1.0' > unbind lsusb -vv &> /tmp/lsusb.log And the attach lsusb.log here ? This will detach the usbhid driver from the keyboard, allowing lsusb to get the full hid descriptors, which should hopefully help us to figure out what is going on. Regards, Hans
Created attachment 946965 [details] lsusb.log
(In reply to Jerry Amundson from comment #14) > Created attachment 946965 [details] > lsusb.log Thanks, all the HID descriptors are there, which is good to have, I'll let Benjamin handle this further as he is the real expert on this.
Just wondering if there is anything additional I can do to help with this ... ?
Apologies for the delay, I did not had the time to look into that before today. So the device I have been reported earlier is slightly different from yours, and yours should definitively be managed by hid-multitouch. To ease the tests, I have pushed a branch (kernels-3.15+) with the (hopefully working) support of your device: $> git clone https://github.com/bentiss/hid-multitouch -b kernels-3.15+ $> cd hid-multitouch $> make $> sudo rmmod hid-multitouch ; sync ; sudo insmod hid-multitouch.ko This should enable the keyboard and also enable the mouse. I would then ask you to send me a hid-recorder trace of your device so I can test it by myself and see if I need to improve the patch or not. For that, just install hid-replay from this copr[1] and capture the hid-recorder output of the Surface TypeCover. Please type things (not your password), and move your fingers on the touchpad (also do some gestures like two fingers scrolls). [1] https://copr.fedoraproject.org/coprs/bentiss/hid-replay/
That worked for me. I was able to get into the machine by using an external keyboard and then apply your patch. Thanks! -Nick
Created attachment 956877 [details] hid-recorder output
(In reply to Jerry Amundson from comment #19) > hid-recorder output Thanks for the log. Just to be sure, this was with hid-multitouch patched? If so, then the upstream choice of using hid-microsoft instead of hid-multitouch makes sense because the touchpad is still in mouse emulation mode.
Yes, hid-multitouch patched and insmod'd.
OK, thanks for the confirmation. Josh, do you think it would be possible to backport the following commit in the F21 (or even F20?) kernel tree? https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-3.19/microsoft&id=be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0 This one is what will 3.19 get, so it should be safe to have it in Fedora.
Added to F20-rawhide kernels. Thanks.
kernel-3.17.3-300.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kernel-3.17.3-300.fc21
kernel-3.17.3-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.17.3-200.fc20
Package kernel-3.17.3-300.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.17.3-300.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15159/kernel-3.17.3-300.fc21 then log in and leave karma (feedback).
kernel-3.17.3-300.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.17.3-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.