[Surface Pro 2] Keyboard Touch Cover 2 not working

[uboot fanat]

When I boot the surface pro 2 device with a fresh installation of ubuntu (the gnome flavour) with current updates and attach the Touch Cover 2-keyboard, I expect the keyboard to work.

What happens:
The keyboard does not work. xev does not raise any events from the keyboard.

Note:
since I do not have an internet connection from the device in question, I cannot provide you with the requested ubuntu-bug output.

Question:
I attached anything I can think of which might be helpful to resolve the issue. Please point me in the right direction on how I can debug this further.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1248958

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Quinn Balazs (qbalazs)]

If possible, it would be very helpful to have the ~/dmesg and /var/log/Xorg.0.log. If you manage to get those attached, we can take a look at your issue. If you are unable to capture ~/dmesg and Xorg.0.log, we can still attempt to figure this out, it will just be a bit harder.

Quinn Balazs

[uboot fanat (ubootfanat)]

Thanks. Please find the full logs attached.

I do not have internet access from the device (see Bug #1248917). So any tool that needs internet access does not work. Sorry.

[Quinn Balazs (qbalazs)]

I think the issue here is in interpreting the data given by the keyboard. In your kernel log, there should be a line something like this "hid-multitouch 0003:045E:07A9.xxxx....." with a hidraw number after it. If you run "# cat /dev/hidraw#", you should see that the keyboard is indeed spewing data, it just isn't being read correctly. The "Microsoft SAM" device that X registers appears to be the windows key capacitive button, not the keyboard at all. If you get a chance, check that out, and let us know if there is info produced by the keyboard.

Quinn Balazs

[uboot fanat (ubootfanat)]

yes confirmed. cat /dev/hidraw# spews data.

I was missled by the syslog update whenever I snap the keyboard on or off (the fragment in the system info and logs attachment).

so I messed around with "udevadm monitor" and looked again at dmesg. When I snap the keyboard on the dmesg says "HID_DG_INPUTMODE out of range -> No inputs registered" (full excerpt attached).

so thats seems to be why /dev/hidraw# spews data but is not heard by X.

Yet I am not clear about why the device is disconnected before and an ACPI error is raised.

[uboot fanat (ubootfanat)]

for clarity: hidraw5 happens to be the atmel stylus.

[uboot fanat (ubootfanat)]

http://ubuntuforums.org/showthread.php?t=2183946&p=12841231#post12841231 discovered, that with another kernel the keyboard works due to a different driver.

Can I design a udev rule to use a different driver for the keyboard?

[penalvch (penalvch)]

uboot fanat, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please just make a comment to this?

[goepfling (goepfling)]

No luck with daily live image.

Microsoft TypeCover keyboard only works when the xhci support is disabled.

I also can read data from /dev/hidrawxxx but if I attach an external USB keyboard and switch to a console (ctrl-alt-f1), the TypeCover still doesn't work: it is actually a kernel problem, not a Xorg problem.

Maybe the xhci problem (which also affects Bluetooth and Wifi of the Surface Pro 2) it is related to this kernel warning:
[code]
[ 1.028259] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[/code]

[penalvch (penalvch)]

goepfling, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs