Projecteur: [BUG] No Interactions on Ubuntu 21.10

TL;DR; read Edit2!

I did some investigation and found out something interesting. I recorded the movement with libinput record /dev/input/event## > file.yml and compared the records from the original with moving cursor and from the virtual device without a moving cursor. libinput replay file.yml did what anyone would expect: when replaying the record of the original device, the cursor moves, replaying the virtual device doesn’t move.

BUT: If you change the line in the record file of the virtual device at position devices[0].codecs.1 (EV_KEY) to the same value given in the record of the original device, the cursor moves when replaying. Yaaay! (i.e. [272…287] instead of [1…767]). To get rid of the upcoming warning device is missing recorded udev property, I tried [1…287] and it still works but without this kind of warning (I still get the warning unexpected property: LIBINPUT_DEVICE_GROUP but I guess, this is a different topic)

I don’t know if this helps figuring out what the actual problem is, but I hope it helps a little 😉

Oh, BTW: running fedora 37 workstation on gnome 43.2 with wayland and rpm-installation.

EDIT: I seems there is a problem with key-codes above 562 (0x232). I.e. changing KEY_CNT to KEY_ROTATE_LOCK_TOGGLE in https://github.com/jahnf/Projecteur/blob/323532fcd420f761b885e1a7c68161789aa73dc1/src/virtualdevice.cc#L76 should do the trick. I don’t know, if this has side-effects, it probably crashes key-combinations with keys above this keycode and the root of the problem is still unknown. I mean, whats the problem with keys like KEY_BRIGHTNESS_MENU (649 / 0x289). It makes also no sense, that it “breaks” at this position. There are no keycodes defined between 562 / 0x232 and 575 / 0x23f. linux/input-event-codes.h

EDIT2: I think I got it:

ID_INPUT_KEYBOARD, ID_INPUT_KEY, ID_INPUT_MOUSE, ID_INPUT_TOUCHPAD, ID_INPUT_TOUCHSCREEN, ID_INPUT_TABLET, ID_INPUT_JOYSTICK, ID_INPUT_ACCELEROMETER If any of the above is set, libinput initializes the device as the given type, see Device type assignment via udev. Note that for historical reasons more than one of these may be set at any time, libinput will select only one of these to determine the device type. To ensure libinput selects the correct device type, only set one of them. https://wayland.freedesktop.org/libinput/doc/1.10.7/udev_config.html

long story short: We will need two virtual devices, one for the virtual mouse and one for the keyboard. I don’t know, what the difference between ID_INPUT_KEY and ID_INPUT_KEYBOARD is, but this seems to be a valid combination “for historical reasons”. At least my cherry-keyboard has this combination and it works.

EDIT3: Everything with key-ids between BTN_MOUSE (272 / 0x110) and BTN_JOYSTICK - 1 (287 / 0x11f) is considered a mouse, everything else is not. (udev-builtin-input_id.c#L185). This correlates with the keycodes of the original device. ID_INPUT_KEY is always set with ID_INPUT_KEYBOARD (udev-builtin-input_id.c#L299-L308)

EDIT4: Changing the keycodes to the mentioned above brings back the mouse-functionality but disables all keymappings (for obvious reasons). skipping them brings the mappings back to libinput debug-events but it still doesn’t work, although udevadm doesn’t mention ID_MOUSE=1 anymore.

EDIT5: I tried the following code:

  // Set all key code bits on virtual device
  const bool keyboard = true;
  const bool mouse = true;
  const bool upper_keys = true;
  if (keyboard) {
    for (int i = 1; i < BTN_MISC; ++i) {
      ioctl(fd, UI_SET_KEYBIT, i);
    }
  }
  if (mouse) {
    for (int i = BTN_MISC; i < KEY_OK; ++i) {
      ioctl(fd, UI_SET_KEYBIT, i);
    }
  }
  if (keyboard) {
    for (int i = KEY_OK; i < KEY_MACRO1; ++i) {
      ioctl(fd, UI_SET_KEYBIT, i);
    }
  }
  if (upper_keys) {
    for (int i = KEY_MACRO1; i < KEY_CNT; ++i) {
      ioctl(fd, UI_SET_KEYBIT, i);
    }
  }

keyboard with anything else (current state: all true): (KMU, KM, KU)

• mouse movement
• key mappings
• scrolling
• mouse button

only keyboard: (K)

• mouse movement
• key mappings
• scrolling
• mouse button

mouse with or without upper_keys: (MU, M)

• mouse movement
• key mappings
• scrolling
• mouse button

everything false or only upper_keys: (U, ø)

• mouse movement
• key mappings
• scrolling
• mouse button

conclusion: mouse and keyboard must not be used in the same virtual device if the mouse-button and keymappings should work. upper_keys crash the keyboard. I didn’t check the spotlight functionality on all 8 combinations, it behaves different and there are probably some independent issues with wayland.

sorry for the late reply, tested it now on several occasions and so far the new branch is working great for me with gnome+wayland.

It is definitely related on how to uinput and wayland on newer distribution releases. Sadly I do not have a quick fix or workaround at the moment. I need to see how other projects might solve this issue.

Ah thanks projecteur --disable-uinput works for me on wayland (with the normal circle pointer)!

Good to know, of course the nice feature of mapping custom inputs is disabled 😞 - so this is only kind of a workaround. Seems one issue is around the area of grabbing all the device input and feeding it (mapped) to a virtual uinput device. That definitely narrows down my issue tracking.

Ah thanks projecteur --disable-uinput works for me on wayland (with the normal circle pointer)!

Yes. I had some older version of projecteur on 21.04, updated to 0.9.2 when I found that it doesn’t work anymore, but that did not help … 😃 Let be know if I can be of any assistance.