Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

insmod: could not insert module virtual_touchscreen.ko: Key was rejected by service #10

Open
vitoo opened this issue Nov 30, 2023 · 11 comments

Comments

@vitoo
Copy link

vitoo commented Nov 30, 2023

Hello,

i am trying to install

insmod virtual_touchscreen.ko 
insmod: ERROR: could not insert module virtual_touchscreen.ko: Key was rejected by service

do you know a workaround ?

thanks

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

After disabling secure boot, it load the module but touchscreen dont happen, i dont see touchscreen "touch" on my screen, and no /dev/virtual_touchscreen device

dmesg | grep virtual_touchscreen
[    6.285138] virtual_touchscreen: loading out-of-tree module taints kernel.
[    6.285171] virtual_touchscreen: module verification failed: signature and/or required key missing - tainting kernel
[    6.285521] virtual_touchscreen: Major=239

@vi
Copy link
Owner

vi commented Nov 30, 2023

To use the module with secure boot, you need to build and sign it in a certain, peculiar way (provided you use your own key for secure boot and can decide what is allowed and what is not).


/dev/virtual_touchscreen should be created by udev. Messages suggest that the module is indeed loaded. You may want to create the device manually with mknod /dev/virtual_touchscreen c 239 0 or something like that (that's why it also shows the major device number in dmesg).

After that you can also need to propagate the other end of virtual_touchscreen to the GUI. With xorg and udev it typically happens automatically, but if /dev/virtual_touchscreen failed to automatically appear then /dev/input/ things would likely also require some work.

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

Thanks, now i have a /dev/virtual_touchscreen after mknod cmd

but :

root@debian:/home/vito# cat /dev/virtual_touchscreen
cat: /dev/virtual_touchscreen: No such device or address

i am using xorg (x11), can you tell me what should i do next please ?

when i run ./virtual_touchscreen.clj i have this logs :

./virtual_touchscreen.clj 
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.lang.InjectedInvoker/0x00000008401e8040 (file:/usr/share/java/clojure-1.10.2.jar) to method sun.java2d.SunGraphics2D.drawRect(int,int,int,int)
WARNING: Please consider reporting this to the maintainers of clojure.lang.InjectedInvoker/0x00000008401e8040
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

@vi
Copy link
Owner

vi commented Nov 30, 2023

I tried running clojure virtual_touchscreen.clj on my system (Debian Bookworm) and it just worked (i.e. showed the window), though it also showed that warning.

Note that there is a pre-built jar, which may work some other way.

The GUI was created long ago, when Clojure was probably different and Java Swing was a thing.


should i do next please

Try cat /dev/virtual_touchscreen and ensure it shows the help message.

Then you should check (or create if needed) new /dev/input/event* node and perform some simple tests like described in the README to ensure virtual_touchscreen does indeed transform incoming commands to input events. You may want to use evdev-dump tool if it is available.

When you see that new virtual_touchscreen's evdev input device does work, you should connect the GUI to /dev/virtual_touchscreen (e.g. using netcat) and see that maybe it propagated to xorg automatically. If not, you should check with xinput that virtual_touchscreen device is indeed seen in xorg and take some steps (e.g. restart xorg or reconfigure it somehow) if not. On the X side you can use xev to analyse events arriving at windows.

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

finally after reboot this work :

root@debian:/home/vito# cat /dev/virtual_touchscreen 
Usage: write the following commands to /dev/virtual_touchscreen:
    x num  - move to (x, ...)
    y num  - move to (..., y)
    d 0    - touch down
    u 0    - touch up
    s slot - select multitouch slot (0 to 9)
    a flag - report if the selected slot is being touched
    e 0   - trigger input_mt_report_pointer_emulation
    X num - report x for the given slot
    Y num - report y for the given slot
    S 0   - sync (should be after every block of commands)
    M 0   - multitouch sync
    T num - tracking ID
    also 0123456789:; - arbitrary ABS_MT_ command (see linux/input.h)
  each command is char and int: sscanf("%c%d",...)
  <s>x and y are from 0 to 1023</s> Probe yourself range of x and y
  Each command is terminated with '\n'. Short writes == dropped commands.
  Read linux Documentation/input/multi-touch-protocol.txt to read about events

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

xinput give me :

⎜ ↳ Virtual touchscreen id=16 [slave pointer (2)]

it mean i can analyse with : hd /dev/input/event16 ?

so this bellow should be enough ?

java -jar virtual_touchscreen.jar 
nc localhost 9494 > /dev/virtual_touchscreen

thanks for your help

@vi
Copy link
Owner

vi commented Nov 30, 2023

↳ Virtual touchscreen id=16 [slave pointer (2)]

It probably means that the virtual touchscreen is ready to go.

nc localhost 9494 > /dev/virtual_touchscreen

While having this on, if you drag the touchers to the touch area in the GUI you should see some input disruptions, but it is typically not convenient to control the virtual touchscreen from the same device it is connected to.

You can run the GUI on one host (controlling) and nc 192.168.0.2 9494 > /dev/virtual_touchscreen on the controlled host. That way you can send touch events across the network. 192.168.0.2 here is example of controlling host's IP address.

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

i have 2 screens, so it should be practical no ?

i think it worked, because when i move the touch 0, the mouse moved, but then the GUI freeze, touch 0 is not visible and i can't use the GUI :

image

@vi
Copy link
Owner

vi commented Nov 30, 2023

i have 2 screens, so it should be practical no

Unlikely.

Maybe you want something like multiple mouse cursors - one real and others virtual? Maybe you can set up something like multi-pointer with virtual_touchscreen, but I haven't tried that myself.

Typically multiple touchers in virtual touchscreen is mutliple virtual fingers on one touchscreen, allowing to simulate gestures like pinch to zoom, rotate, etc.


What do you want to do with virtual_touchscreen in general?

The GUI is not the only thing you can connect to it, it is mostly to show example of an event sequence that /dev/virtual_touchscreen meaningfully accept.

@vitoo
Copy link
Author

vitoo commented Nov 30, 2023

I need to test touch event on qemu 8 GUI (gtk gui), for a windows VM

I dont want to buy a PC touchscreen for this :D

@vi
Copy link
Owner

vi commented Nov 30, 2023

Maybe you can supply touch events to qemu some other way, not by emulating the touchscreen on Linux kernel level? Or maybe you can forward evdev to qemu directly, not though xorg? Or maybe you can make multi-pointer setup and grab one of those pointers in qemu?

If PC touchscreen is a USB device and production system will use the same touchscreen model then testing with the same model of the touchscreen may be more reliable and more representative of the production system. Qemu can forward USB devices into the VM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants