Bug 1403301

Created attachment 1230025 [details]
F25 lsusb.log

+++ This bug was initially created as a clone of Bug #1135338 +++

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

--- Additional comment from Hans de Goede on 2014-08-29 03:02:21 EDT ---

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.

--- Additional comment from Hans de Goede on 2014-08-29 03:04:24 EDT ---

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?

--- Additional comment from Nicholas Nachefski on 2014-08-29 12:40:03 EDT ---

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

--- Additional comment from Nicholas Nachefski on 2014-08-29 12:43:06 EDT ---

It is indeed USB.  See attachment.

--- Additional comment from Nicholas Nachefski on 2014-08-29 13:13:12 EDT ---



--- Additional comment from Hans de Goede on 2014-08-29 15:10:47 EDT ---

(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

--- Additional comment from Nicholas Nachefski on 2014-09-02 12:50:10 EDT ---

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.

--- Additional comment from Nicholas Nachefski on 2014-09-02 12:51:05 EDT ---

*pad

--- Additional comment from Hans de Goede on 2014-09-14 17:05:51 EDT ---

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

--- Additional comment from Jerry Amundson on 2014-10-10 16:03:11 EDT ---



--- Additional comment from Jerry Amundson on 2014-10-10 16:04:11 EDT ---



--- Additional comment from Jerry Amundson on 2014-10-10 16:10:46 EDT ---

On my SP3, *nothing* gets recorded - keyboard and pad both give nothing.

--- Additional comment from Hans de Goede on 2014-10-11 05:26:15 EDT ---

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

--- Additional comment from Jerry Amundson on 2014-10-14 11:52:50 EDT ---



--- Additional comment from Hans de Goede on 2014-10-15 05:52:30 EDT ---

(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.

--- Additional comment from Jerry Amundson on 2014-10-28 16:35:40 EDT ---

Just wondering if there is anything additional I can do to help with this ... ?

--- Additional comment from Benjamin Tissoires on 2014-10-30 17:00:32 EDT ---

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/

--- Additional comment from Nicholas Nachefski on 2014-10-30 18:19:43 EDT ---

That worked for me.  I was able to get into the machine by using an external keyboard and then apply your patch.  Thanks!

-Nick

--- Additional comment from Jerry Amundson on 2014-11-12 16:16:24 EST ---



--- Additional comment from Benjamin Tissoires on 2014-11-13 09:56:07 EST ---

(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.

--- Additional comment from Jerry Amundson on 2014-11-13 10:02:09 EST ---

Yes, hid-multitouch patched and insmod'd.

--- Additional comment from Benjamin Tissoires on 2014-11-13 10:22:13 EST ---

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.

--- Additional comment from Josh Boyer on 2014-11-13 14:56:57 EST ---

Added to F20-rawhide kernels.  Thanks.

--- Additional comment from Fedora Update System on 2014-11-15 10:03:27 EST ---

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

--- Additional comment from Fedora Update System on 2014-11-15 11:44:31 EST ---

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

--- Additional comment from Fedora Update System on 2014-11-16 09:39:49 EST ---

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).

--- Additional comment from Fedora Update System on 2014-11-18 07:17:02 EST ---

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.

--- Additional comment from Fedora Update System on 2014-11-20 18:03:44 EST ---

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.