Ortek Wireless Keyboard with Touchpad - Keyboard does not work

Same issue with Ubuntu 8.04 lts AMD64

Setting status to "Confirmed" based on sismo's comment.

Sismo/Cocodude, could you please test this with the latest Ubuntu Karmic release and see if the problem persists? Thanks!

I too have this exact problem. Same symptoms and similar message log entries.
I would prefer not to upgrade my machine to a Beta, but would be happy to test a particular driver - if that helps.

I'll check out the current status of this with Karmic when it is released next week.

Andy/Cocodude, if you want to test without upgrading your system to a beta version of Ubuntu, feel free to download and boot from a LiveCD here: http://releases.ubuntu.com/karmic/

I can do the test. I have karmic on the notebook. I will do at home (i'm on work now).

Keeps failing. On 9.10

dmesg
[ 9327.482912] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.0/input/input13
[ 9327.483082] generic-usb 0003:05A4:2000.0003: input,hidraw0: USB HID v1.10 Keyboard [ORTEK Smartpad Keyboard] on usb-0000:00:1d.1-2/input0
[ 9327.494475] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.1/input/input14
[ 9327.494770] generic-usb 0003:05A4:2000.0004: input,hiddev96,hidraw1: USB HID v1.10 Mouse [ORTEK Smartpad Keyboard] on usb-0000:00:1d.1-2/input1

lsusb |grep Ortek
Bus 006 Device 002: ID 05a4:2000 Ortek Technology, Inc.

uname -a
Linux fatass 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux

The touch pad works fine, but the keyboard doesn't seems to work at all.

lsmod
Module Size Used by
nls_iso8859_1 3740 0
nls_cp437 5372 0
vfat 10716 0
fat 51452 1 vfat
usb_storage 52544 0
aes_i586 8124 1
aes_generic 27484 1 aes_i586
vmnet 40124 19
parport_pc 31940 0
vmci 49588 0
vmmon 71184 0
binfmt_misc 8356 1
bridge 47952 0
stp 2272 1 bridge
bnep 12060 2
ppdev 6688 0
autofs4 25568 1
nfsd 241100 9
exportfs 4412 1 nfsd
nfs 271912 0
lockd 67724 2 nfsd,nfs
nfs_acl 2844 2 nfsd,nfs
auth_rpcgss 36576 2 nfsd,nfs
sunrpc 191712 10 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
dm_crypt 12928 0
snd_hda_codec_realtek 203328 1
arc4 1660 2
snd_hda_intel 26920 2
ecb 2524 2
snd_hda_codec 75708 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 7200 1 snd_hda_codec
snd_pcm_oss 37920 0
snd_mixer_oss 16028 1 snd_pcm_oss
rt73usb 26336 0
crc_itu_t 1852 1 rt73usb
iptable_filter 3100 0
snd_pcm 75296 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
rt2x00usb 11548 1 rt73usb
rt2x00lib 29756 2 rt73usb,rt2x00usb
ip_tables 11692 1 iptable_filter
snd_seq_dummy 2656 0
snd_seq_oss 28576 0
snd_seq_midi 6432 0
snd_rawmidi 22208 1 snd_seq_midi
input_polldev 3716 1 rt2x00lib
x_tables 16544 1 ip_tables
joydev 10272 0
mac80211 181236 2 rt2x00usb,rt2x00lib
snd_seq_midi_event 6940 2 snd_seq_oss,snd_seq_midi
uvcvideo 59080 0
snd_seq 50224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
btusb 11856 2
videodev 36736 1 uvcvideo
cfg80211 93052 2 rt2x00lib,mac80211
snd_timer 22276 2 snd_pcm,snd_seq
v4l1_compat 14496 2 uvcvideo,videodev
snd_seq_device 6920 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
pcmci...

I am in the same situation, using ubuntu hardy on my laptop,

Is there a possibilty that the ortek keyboard might be used?
I thought it was a matter of protocol that could not be decrypted.

thank you

---Pol

On 10/23/09, sismo <email address hidden> wrote:
> Keeps failing. On 9.10
>
> dmesg
> [ 9327.482912] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.0/input/input13
> [ 9327.483082] generic-usb 0003:05A4:2000.0003: input,hidraw0: USB HID v1.10 Keyboard [ORTEK Smartpad Keyboard] on usb-0000:00:1d.1-2/input0
> [ 9327.494475] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.1/input/input14
> [ 9327.494770] generic-usb 0003:05A4:2000.0004: input,hiddev96,hidraw1: USB HID v1.10 Mouse [ORTEK Smartpad Keyboard] on usb-0000:00:1d.1-2/input1
>
> lsusb |grep Ortek
> Bus 006 Device 002: ID 05a4:2000 Ortek Technology, Inc.
>
> uname -a
> Linux fatass 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
>
> The touch pad works fine, but the keyboard doesn't seems to work at all.
>
> lsmod
> Module Size Used by
> nls_iso8859_1 3740 0
> nls_cp437 5372 0
> vfat 10716 0
> fat 51452 1 vfat
> usb_storage 52544 0
> aes_i586 8124 1
> aes_generic 27484 1 aes_i586
> vmnet 40124 19
> parport_pc 31940 0
> vmci 49588 0
> vmmon 71184 0
> binfmt_misc 8356 1
> bridge 47952 0
> stp 2272 1 bridge
> bnep 12060 2
> ppdev 6688 0
> autofs4 25568 1
> nfsd 241100 9
> exportfs 4412 1 nfsd
> nfs 271912 0
> lockd 67724 2 nfsd,nfs
> nfs_acl 2844 2 nfsd,nfs
> auth_rpcgss 36576 2 nfsd,nfs
> sunrpc 191712 10 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
> dm_crypt 12928 0
> snd_hda_codec_realtek 203328 1
> arc4 1660 2
> snd_hda_intel 26920 2
> ecb 2524 2
> snd_hda_codec 75708 2 snd_hda_codec_realtek,snd_hda_intel
> snd_hwdep 7200 1 snd_hda_codec
> snd_pcm_oss 37920 0
> snd_mixer_oss 16028 1 snd_pcm_oss
> rt73usb 26336 0
> crc_itu_t 1852 1 rt73usb
> iptable_filter 3100 0
> snd_pcm 75296 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
> rt2x00usb 11548 1 rt73usb
> rt2x00lib 29756 2 rt73usb,rt2x00usb
> ip_tables 11692 1 iptable_filter
> snd_seq_dummy 2656 0
> snd_seq_oss 28576 0
> snd_seq_midi 6432 0
> snd_rawmidi 22208 1 snd_seq_midi
> input_polldev 3716 1 rt2x00lib
> x_tables 16544 1 ip_tables
> joydev 10272 0
> mac80211 181236 2 rt2x00usb,rt2x00lib
> snd_seq_midi_event 6940 2 snd_seq_oss,snd_seq_midi
> uvcvideo ...

I also have tested Ubuntu 9.10 Beta (on an ASUS laptop) and still have the same problem - no keyboard but mousepad works fine, so do the volume buttons and calc, etc buttons.

I haven't looked at the source code, but are there debug flags that we could easily turn on to find where this keyboard is failing?

-Andy.

Hi i am having the same problem on latest 9.10, has any one had any luck?

i have the same problem an i-m even new to linux .... please help me ...

Same problem.

Usbmon trace (pressing qwert)

 cat /sys/kernel/debug/usb/usbmon/6u
f64afd80 3359359859 C Ii:6:002:1 0:8 8 = 00001400 00000000
f64afd80 3359359870 S Ii:6:002:1 -115:8 8 <
f64afd80 3359439863 C Ii:6:002:1 0:8 8 = 00000000 00000000
f64afd80 3359439870 S Ii:6:002:1 -115:8 8 <
f64afd80 3361320028 C Ii:6:002:1 0:8 8 = 00001a00 00000000
f64afd80 3361320032 S Ii:6:002:1 -115:8 8 <
f64afd80 3361368032 C Ii:6:002:1 0:8 8 = 00000000 00000000
f64afd80 3361368037 S Ii:6:002:1 -115:8 8 <
f64afd80 3362912167 C Ii:6:002:1 0:8 8 = 00000800 00000000
f64afd80 3362912171 S Ii:6:002:1 -115:8 8 <
f64afd80 3362960171 C Ii:6:002:1 0:8 8 = 00000000 00000000
f64afd80 3362960176 S Ii:6:002:1 -115:8 8 <
f64afd80 3367528571 C Ii:6:002:1 0:8 8 = 00001500 00000000
f64afd80 3367528576 S Ii:6:002:1 -115:8 8 <
f64afd80 3367592576 C Ii:6:002:1 0:8 8 = 00000000 00000000
f64afd80 3367592581 S Ii:6:002:1 -115:8 8 <

On another working usb keyboard

edc1d480 3440958998 C Ii:6:004:1 0:8 8 = 00001400 00000000
edc1d480 3440959022 S Ii:6:004:1 -115:8 8 <
edc1d480 3441023007 C Ii:6:004:1 0:8 8 = 00000000 00000000
edc1d480 3441023031 S Ii:6:004:1 -115:8 8 <
edc1d480 3443695236 C Ii:6:004:1 0:8 8 = 00001a00 00000000
edc1d480 3443695252 S Ii:6:004:1 -115:8 8 <
edc1d480 3443767242 C Ii:6:004:1 0:8 8 = 00000000 00000000
edc1d480 3443767256 S Ii:6:004:1 -115:8 8 <
edc1d480 3444399297 C Ii:6:004:1 0:8 8 = 00000800 00000000
edc1d480 3444399311 S Ii:6:004:1 -115:8 8 <
edc1d480 3444479304 C Ii:6:004:1 0:8 8 = 00000000 00000000
edc1d480 3444479319 S Ii:6:004:1 -115:8 8 <
edc1d480 3444687322 C Ii:6:004:1 0:8 8 = 00001500 00000000
edc1d480 3444687336 S Ii:6:004:1 -115:8 8 <
edc1d480 3444751328 C Ii:6:004:1 0:8 8 = 00000000 00000000
edc1d480 3444751341 S Ii:6:004:1 -115:8 8 <

I don't know where to go from here though :-/

I just set up karmic on my workstation and problem still here ... i dont know where to dig

Regarding keyboard part, meta keys like alt, shift, ctrl do work (doing a "cat" on the device in /dev provides characters printing on console, other keys don't), however, sniffing usb transactions with wireshark on the corresponding /dev/usbmonX don't show anything weird (I didn't see inconsistencies between a working keyboard and this one)
So, it seems that packets sent by ortek's keyboard are lost somewhere, since they are received by usb port (wireshark logs on /dev/usbmonX, or cat on /sys/kernel/debug/usb/usbmon/xx ) but do not make their way to the kernel usb device (e.g. /dev/input/by-id/usb-ORTEK_Smartpad_Keyboard-event-kbd)
I guess the problem comes from the multiple interfaces the thing has : (lsusb -t)

/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 6, If 0, Class=HID, Driver=usbhid, 12M
    |__ Port 1: Dev 6, If 1, Class=HID, Driver=usbhid, 12M

It's behaving as if the usb stack was not able to route correctly the packets received.

As do previous commenters, I'm now kind of stuck into reading the content of /usr/share/doc/linux-doc/usb.
Could this bug report be affected to someone, please ?

Hello, I have this keyboard as well. It's being sold by a major UK online retailer: http://www.ebuyer.com/product/158377

I have exactly the same issue, trackpad works but keyboard does not. dmesg reports the multiple HID devices as others have said.

What data needs to be collected in order for this to be fixed? Unless I underestimate the intricacies of USB HID I would expect that this is a problem that the linux distributions/upstream need to address rather than the keyboard manufacturer- as others have pointed out it works out of the box in windows i.e. without any custom driver.

I done some more side to side testing with another wireless usb and mouse set I have made by Creative, that works as you would expect.

I think arehnius has a red herring with regards to the lsusb tree output, I get that whenever both my working and non-working (i.e. ortek) are both plugged in, but not when only one of either are plugged in. That doesn't change the fact that the creative always works and the ortek never does.

By 'not work' I can confirm that it is only the main keys, not the meta keys (ctrl+alt+win) which are picked up when catting the /dev/input device for the keyboard. The trackpad works as expected, as do the volume up/down keys which are picked up when catting the /dev/input device for the mouse.

Note that these keys work fine in grub, I can freely edit the boot line and the keyboard behaves as you would hope.

So I compiled the kernel with some more debug options. See attached the kernel output when connecting and disconnecting both the ortek keyboard and a working keyboard (creative). Hopefully they'll be useful to someone who understands these things more.

Interestingly the keypresses are being picked up somewhat. If I do an "echo 1 > /sys/module/hid/parameters/debug" and then watch the kernel output I am seeing identical output for keys on the working keyboard as I am on the ortek e.g.

Dec 10 23:10:37 fructose kernel: [ 1228.799642] drivers/hid/hid-core.c: report 3 (size 5) = 03 00 02 fe 00
Dec 10 23:10:37 fructose kernel: [ 1228.815633] drivers/hid/hid-core.c: report (size 5) (numbered)

So at this point I presume we have enough information to target the relevant developers to investigate- if hid-core is receiving keystrokes but X isn't getting a keypress event then what glue inbetween isn't doing its job?

EDIT:
I meant by 'not work' I can confirm that it is only the main keys which are NOT picked up when catting the /dev/input device for the keyboard.

The meta keys (ctrl+alt+win) DO work correctly.

Filed a bug at kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=14787

Output from catting the relevant /dev/hidraw device is the same as from a working keyboard, but nothing is received on the corresponding /dev/input/event interface.

Can anyone give any pointers where to go from here? If the same output is received on hidraw then what is involved in generating the evdev output?

I have now fixed this problem locally, the logical maximum value in the usb resource descriptor is incorrect for the keyboard. I worked out the value that needed fixing and modified the existing usb quirk driver for the sunplus keyboard.

I need to generate a more appropriate kernel patch from my changes and submit it to whoever is responsible. If anyone can help with this please let me know, I haven't done any development in the kernel before.

Nice work jmharris!

How hard is the manual fix to do? and is it worth attempting or should we just wait for your kernel patch?

Hi Robert, here are the basic notes of what I've done so far. I'm putting these on the bugzilla.kernel.org as well as I presume that's closer to the people who commit to the kernel.

The USB resource description (for the keyboard part of the device) is:
05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 95 01 75 08 81 01 95 05 75 01 05 08 19 01 29 05 91 02 95 01 75 03 91 01 05 07 19 00 29 91 15 00 25 01 75 08 95 06 81 00 c0

When you cat the relevant rdesc for the device in /sys/kernel/debug/hid this indicates Field(1) has a usage of 146 but the logical maximum is 1. I see from the kernel source code that resource descriptor fixes have been done for other HID devices so I hacked in the manufacturer and device id (0x05a4 and 0x2000 respectively) into hid-ids.h. Then I consulted the USB specification and hijacked the sunplus keyboard quirk driver code to modify the appropriate rdesc bytes simply as follows:

rdesc[55] = 0xff;

Obviously this raises the logical maximum to 255, that may be excessive. Need to review what a sane value for this should be.

I also have the MULTI_INPUT quirk enabled by altering hid-quirks.c which gives me several more /dev/input/event devices for the keyboard and trackpad on this device, but that was done before the rdesc fix- maybe it is not important in order to get the main keyboard working.

For anyone who can't wait for a patch (fair enough) I made these changes against 2.6.32.1 but it's pretty trivial- I think for older kernels the quirk code structure was a little different though.

Could you please notify us on this report if you get informed about inplementation of your patch on the official kernel?

Sorry to those that have been waiting for this. Here is a patch for vanilla linux 2.6.32.3 sources. I have followed the pattern used for other quirky devices in the kernel, so you must enable the new Ortek USB HID driver available at:

-> Device Drivers
  -> HID Devices
    -> Special HID drivers

Then expect to see entries like this in the kernel log:

[ 4.930207] ortek 0003:05A4:2000.0001: Fixing up Ortek WKB-2000 report descriptor.
[ 4.930683] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:04.0/usb3/3-4/3-4:1.0/input/input2
[ 4.930843] ortek 0003:05A4:2000.0001: input,hidraw0: USB HID v1.10 Keyboard [ORTEK Smartpad Keyboard] on usb-0000:00:04.0-4/input0
[ 4.935247] usb 3-4:1.0: uevent
[ 4.935453] usb 3-4: uevent
[ 4.937264] input: ORTEK Smartpad Keyboard as /devices/pci0000:00/0000:00:04.0/usb3/3-4/3-4:1.1/input/input3
[ 4.937385] drivers/usb/core/file.c: looking for a minor, starting at 96
[ 4.937494] ortek 0003:05A4:2000.0002: input,hiddev96,hidraw1: USB HID v1.10 Mouse [ORTEK Smartpad Keyboard] on usb-0000:00:04.0-4/input1

I'm submitting this patch to the kernel bugzilla also.

I have added the patch in unified diff format to http://bugzilla.kernel.org/show_bug.cgi?id=14787

I have installed 2.6.32.3 kernel and applied the patch. All of the relevant files in the /usr/src/... seem to have been updated correctly after installing the patch, but when I run make menuconfig the only options in
-> Device Drivers
  -> HID Devices
    -> Special HID drivers
are for various thrustmaster game controllers.

Any ideas how to get the keyboard to appear in the list?

I have applied the patch against 2.6.33-rc4, built and tested; it works as expected - great work!

We should get this to Dmitry (dot) Torokhov (at) gmail.com ASAP (if not already done) for a late pull request to Linus, for inclusion in 2.6.33-rc5, due in a week and CC stable (at) kernel.org in the patch email. The CC to stable will ensure it hits the 2.6.32 kernel series, which will be the baseline for Ubuntu 10.04 LTS (though it may move to 2.6.33).

Until then, we can simply use the updated mainline kernels:

http://kernel.ubuntu.com/~kernel-ppa/mainline/

(if you have Nvidia or Radeon graphics hardware, enabling the Xorg-edgers PPA will get you better graphics support). Thanks, JM! Here is my 'Tested-by' support for any patch email:

Tested-by: Daniel J Blueman <email address hidden>

I am happy to patch and test in Ubuntu 9.10 (karmic - Linux bluemoose 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux) if you need another tester but I am still a bit new to compiling my own kernel. If anyone could provide some advice on the forum http://ubuntuforums.org/showthread.php?p=8700063 I would be happy to try to patch and test.

I see that the patch has been applied to:
http://www.kernel.org/diff/diffview.cgi?file=/pub/linux/kernel/v2.6/next/patch-v2.6.33-rc5-next-20100128.bz2

Does this sort of change ever get backported to earlier kernels officially? Does it get backported by Debian/Ubuntu/Canonical/etc? For instance, will it become available on Ubuntu Karmic (based on 2.6.31)?

If not, is it easy for me to add the patch myself? If this is not the correct place for these questions then please respond here:
http://ubuntuforums.org/showthread.php?p=8700063

Thanks.

ken,
     Usually the only time we backport a fix to an earlier kernel is if it meets the justification for SRU. For cases like this one, we push the updates to the current version of the kernel only.

Not knowing more about the patch than I do, I have no way to tell you if it will be trivial to apply as there could be dependencies required that are only available in the newer kernel.

I hope this helps,

-JFo

This patch has been committed in Lucid. It will not apply to Karmic or Hardy as its a change that is not SRU-able anymore to Karmic.
Please refer to https://wiki.ubuntu.com/StableReleaseUpdates for more details.

This bug was fixed in the package linux - 2.6.32-14.19

---------------
linux (2.6.32-14.19) lucid; urgency=low

  [ Andy Whitcroft ]

  * ensure we build the source package contents when enabled
    - LP: #522308
  * [Config] enable CONFIG_X86_MCE_XEON75XX
  * SAUCE: AppArmor -- add linux/kref.h for struct kref
  * [Config] enable CONFIG_HID_ORTEK
  * enable udeb generation for arm versatile flavour
    - LP: #522515

  [ John Johansen ]

  * ubuntu: AppArmor -- update to mainline 2010-02-18
    - LP: #439560, #496110, #507069

  [ Johnathon Harris ]

  * SAUCE: HID: add support for Ortek WKB-2000
    - LP: #405390

  [ Upstream Kernel Changes ]

  * tpm_tis: TPM_STS_DATA_EXPECT workaround
    - LP: #490487
  * x86, mce: Xeon75xx specific interface to get corrected memory error
    information
  * x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll
  * x86, mce: Make xeon75xx memory driver dependent on PCI
  * drm/edid: Unify detailed block parsing between base and extension
    blocks
    - LP: #500999
  * (pre-stable) eCryptfs: Add getattr function
    - LP: #390833
 -- Andy Whitcroft <email address hidden> Thu, 18 Feb 2010 19:22:02 +0000