2

OP entirely re-edited.

My Razer Cynosa chroma is one physical device (basically no more than a PC_105 keyboard) offering the particularity to offer 3 interfaces (1) one of them for simultaneously sending some scancode and another for sending some internally transcoded mouse report when whatever key is depressed.

I am looking for a way to use the latter as a mouse under X.

All the 3 interfaces are correctly enumerated at boot time and bound to the appropriate hid-generic in-kernel built driver (2)

Then rebound to the razerkbd driver at modeprobe time (3)

Each one of these being later on associated to input events and registered by the X11 server (xorg-server-21.1.4) :

  • In an usual way for such devices regarding the first interface of keyboard type (device id 9) and the third of mouse type (device id 11) (4)
  • In some unusual to me and at least ambiguous way for the second of keyboard type (device id 10). (5) (Cf. the Configuring as mouse / Configuring as keyboard sequence)

All this leading to confusing reports

$ xinput --list --short ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ MOSART Semi. 2.4G Wireless Mouse id=8 [slave pointer (2)] ⎜ ↳ Razer Razer Cynosa Chroma id=10 [slave pointer (2)] ⎜ ↳ Razer Razer Cynosa Chroma id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Razer Razer Cynosa Chroma id=9 [slave keyboard (3)]

(device id 10 reported only as slave pointer whereas initially registered of KEYBOARD type.)

Having noticed that cat /dev/input/event5 printouts mouslike communication when depressing any key and since event5 is linked to device id 10, xinput --test-xi2 10 only logs keyboard events type 13 (RawKeyPress) and 14 (RawKeyRelease)

Would evdev be somehow confused ?

1 : lsusb -vs 008:002 report :

$ lsusb -vs 008:002 Bus 008 Device 002: ID 1532:022a Razer USA, Ltd Cynosa Chroma Device Descriptor: … Configuration Descriptor: … bNumInterfaces 3 … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 1 Keyboard … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 2 Mouse …

2 : Bootlog enumeration of usb devices

[kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input4 [kernel] hid-generic 0003:1532:022A.0002: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input0 [kernel] input: Razer Razer Cynosa Chroma Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input5 [kernel] input: Razer Razer Cynosa Chroma Consumer Control as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input6 [kernel] hid-generic 0003:1532:022A.0003: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input1 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input9 [kernel] hid-generic 0003:1532:022A.0004: input: USB HID v1.11 Mouse [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input2

3 : Rebinding of Razer interfaces at modprobe time

[kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input10 [kernel] razerkbd 0003:1532:022A.0002: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input0 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input11 [kernel] razerkbd 0003:1532:022A.0003: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input1 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input12 [kernel] razerkbd 0003:1532:022A.0004: input: USB HID v1.11 Mouse [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input2

4 : XCONFIG-ing of first keyboard interface and mouse interface

config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event4) Razer Razer Cynosa Chroma: Applying InputClass "evdev keyboard catchall" Razer Razer Cynosa Chroma: Applying InputClass "system-keyboard" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event4 13:68 fd 39 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event4" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found keys evdev: Razer Razer Cynosa Chroma: Configuring as keyboard Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input10/event4" Adding extended input device "Razer Razer Cynosa Chroma" (type: KEYBOARD, id 9) Option "xkb_rules" "evdev" config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event6) Razer Razer Cynosa Chroma: Applying InputClass "evdev pointer catchall" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event6 13:70 fd 41 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event6" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found 9 mouse buttons evdev: Razer Razer Cynosa Chroma: Found scroll wheel(s) evdev: Razer Razer Cynosa Chroma: Found relative axes evdev: Razer Razer Cynosa Chroma: Found x and y relative axes evdev: Razer Razer Cynosa Chroma: Configuring as mouse evdev: Razer Razer Cynosa Chroma: Adding scrollwheel support evdev: Razer Razer Cynosa Chroma: YAxisMapping: buttons 4 and 5 evdev: Razer Razer Cynosa Chroma: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input12/event6" XINPUT: Adding extended input device "Razer Razer Cynosa Chroma" (type: MOUSE, id 11) evdev: Razer Razer Cynosa Chroma: initialized for relative axes. Razer Razer Cynosa Chroma: (accel) keeping acceleration scheme 1 Razer Razer Cynosa Chroma: (accel) acceleration profile 0 Razer Razer Cynosa Chroma: (accel) acceleration factor: 2.000 Razer Razer Cynosa Chroma: (accel) acceleration threshold: 4

5 : Ambiguous XCONFIG-ing of second keyboard interface

config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event5) Razer Razer Cynosa Chroma: Applying InputClass "evdev keyboard catchall" Razer Razer Cynosa Chroma: Applying InputClass "system-keyboard" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event5 13:69 fd 40 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event5" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found 1 mouse buttons evdev: Razer Razer Cynosa Chroma: Found scroll wheel(s) evdev: Razer Razer Cynosa Chroma: Found relative axes evdev: Razer Razer Cynosa Chroma: Forcing relative x/y axes to exist. evdev: Razer Razer Cynosa Chroma: Found absolute axes evdev: Razer Razer Cynosa Chroma: Forcing absolute x/y axes to exist. evdev: Razer Razer Cynosa Chroma: Found keys evdev: Razer Razer Cynosa Chroma: Configuring as mouse evdev: Razer Razer Cynosa Chroma: Configuring as keyboard evdev: Razer Razer Cynosa Chroma: Adding scrollwheel support evdev: Razer Razer Cynosa Chroma: YAxisMapping: buttons 4 and 5 evdev: Razer Razer Cynosa Chroma: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input11/event5" XINPUT: Adding extended input device "Razer Razer Cynosa Chroma" (type: KEYBOARD, id 10) Option "xkb_rules" "evdev" evdev: Razer Razer Cynosa Chroma: initialized for relative axes. evdev: Razer Razer Cynosa Chroma: ignoring absolute axes. Razer Razer Cynosa Chroma: (accel) keeping acceleration scheme 1 Razer Razer Cynosa Chroma: (accel) acceleration profile 0 Razer Razer Cynosa Chroma: (accel) acceleration factor: 2.000 Razer Razer Cynosa Chroma: (accel) acceleration threshold: 4
Improve this question
6
  • Does the keyboard have some sort of built-in trackpad? How would it work as a mouse? Can you see "mouse stuff" reported if you run xev and then use the "mouse"? Commented Dec 6, 2022 at 17:50
  • @terdon : no "physical" mouse of any sort. The physical device is nothing but a PC-105 keys keyboard. The "pseudo" mouse is nothing but some in-device translation of key pressed into standard usb hid mouse protocol. I do not get xev. However, if I cat /dev/input/event[number associated to pseudo mouse] each keyboard key depress will result in the display of characters absolutely similar to those a "real" mouse would send. Commented Dec 6, 2022 at 18:09
  • Can you see the "keyboard mouse" with xinput? Commented Dec 21, 2022 at 11:47
  • @dirkt : Yes indeed! xinput --list --short 11 actually outputs : Razer Razer Cynosa Chroma id=11 [slave pointer (2)] Commented Dec 21, 2022 at 12:15
  • 1
    Can you also see the events with xinput --test-xi2 11 (assuming the id hasn't changed on reboot)? If yes, you can move this device under the core pointer device. Commented Dec 22, 2022 at 7:45

1 Answer 1

Reset to default
1
+50

A bit of background: X started out with a single mouse and a single keyboard. The XINPUT extension (which is now in the second major versions) made this a lot more flexible. It kept the original single mouse and single keyboard as "core pointer" and "core keyboard", but allowed additional "masters" like the core pair, and turned all devices into slaves which can be attached to masters. X applications can also query XINPUT events directly, but very few applications actually do that; most applications just react to "core" events.

By default (at least on my system), all evdev devices are attached to the "core" master, either as keyboard or mouse. Apparently this didn't work on your system. You can see the current mapping with xinput --list, and regardless of the mapping, you can check with xinput --test-xi2 <device id> if some device actually produces output.

For completeness, if you need to debug events on a lower level (before X processes them), then evtest can help to see what goes on at the kernel input layer.

So if you can see mouse events with xinput --test-xi2 <razor id>, and for some reason your "Razer keyboard mouse" is not usable because it's not attached to the core pointer, then you can deattach it if necesary with xinput --float <razor id> and attach it to the core pointer with `xinput --reattach <core pointer id'.

If something else is going on (I don't know what, so far you didn't provide any additional information), e.g. if you are getting keyboard events on the "Razer keyboard mouse", then it'll get more complicated.

And even if your udev and/or xorg.conf is messed up, it should be possible to get everything into a working state with command line tools (unless there is something more fundamentally wrong, like no mouse events). Once you have accomplished this, you can look at the configuration files to make it permanent.

Ok, with the new information: You have three input layer devices (not two as I tought based on the original question), and three corresponding X devices, one keyboard, one mouse, one kind of hybrid.

So the first step is to figure out what those devices do, on the kernel input layer. So run evtest on all three. While you are at it, make sure to use the symlinks in /dev/input/by-* to refer to all three, pick the ones that are most convenient to you (by-id is probably sufficient). Please edit your question with a bit of relevant output for all three, together with which keys you pressed, and if that key produces the expected effect.

Repeat this with xinput --test-xi2 ... for all three devices, see if the events get correctly translated to X.

If you have two devices producing X pointer events (e.g. if both the hybrid and the mouse one produce them), float the hybrid device. Then it should work, use xev to test if necessary.

If none of the devices produce X pointer events, then we need to look at more details to figure out what is going on.

Improve this answer
1
  • +1 for your help and bounty awarded as promised since your answer is absolutely correct with regards to the OP when you answered. I completely rewrote it with more details regarding the inconsistency. Commented Dec 27, 2022 at 13:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.