NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to compile uinput module on cRIO 9030

Hello.. I'm using a cRIO 9030 with NI Real-Time x64 3.14.40-rt37-3.0.0f1. I'm trying to compile the uinput kernel module needed by the touchscreen and obtain a uinput.ko module.

I've followed the procedure reported in the document https://decibel.ni.com/content/docs/DOC-38959 to add uinput.c to kernel module but a series of errors occurs. Attached the file resulting after "make" execution (error.txt).

The code was downloaded from https://gist.github.com/epitron/6760108.

I've also tryed the uinput.h files from http://lxr.free-electrons.com/source/include/linux/uinput.h?v=3.14 and also in this case the compilatin is interrupted (error1.txt)

The downloaded version is 3.14. How can I solve the problem and compile di uinput.ko module?

Thank you for your support

Download All
0 Kudos
Message 1 of 73
(11,791 Views)

you have linked to the source file of how to use the uinput module in user-space, not the source code to the uinput module itself.

A quick google search returned this source code:

    http://lxr.free-electrons.com/source/drivers/input/misc/uinput.c

Unknown what version of the kernel that is for, or if it will work on the NI device.  I would suggest looking for the specific version of uinput that works with the kerenl that is running on your NI device.


Once you build that code, you can use the source code you linked to to interact with the new device driver.

-TD

Message 2 of 73
(5,783 Views)

Thanks tduffy, I was waiting for this thread to be created prior to responding with, well, basically what you wrote. Only difference was the version: http://lxr.free-electrons.com/source/drivers/input/misc/uinput.c?v=3.14 (specifically for 3.14, of course, you could just download the kernel source as NI used to build the kernel, https://github.com/ni/linux/tree/nilrt_pub/15.0/3.14)

0 Kudos
Message 3 of 73
(5,783 Views)

The replies before mine already covered the fact that the driver is present in the NI kernel source but it is not enabled by default so it requires you to download the source from github and re-compile the kernel.

However before you jump through all those hoops can you provide a bit more details about the touchscreen you are trying to use? A lot of them work with the generic driver already present in the kernel.

What happens if you plug in the touch screen and reboot the target? Does it react at all to touch events?

The output from running the following commands in a console would be helpful in diagnosing the problem (make sure you run these with the touch screen plugged in and Embedded UI enabled):

  • dmesg
  • cat /proc/bus/input/devices
  • xinput --list

Also can you post the following log files:

  • /var/log/Xorg.0.log
  • /var/log/Xsession.log

Another useful tool for diagnosing input problems is evtest. You can find a version I've hacked together in an .ipk in this discussion thread: https://decibel.ni.com/content/message/115075

0 Kudos
Message 4 of 73
(5,783 Views)

Thank you both for your support, grat help.

I solved by downloading the NI kernel (https://github.com/ni/linux/tree/nilrt_pub/15.0/3.14) and copyng the Makefile in the directory

/drivers/input/misc/

and excecute make command. The uinput.c has been compiled.

Thank you again for the support

M.

0 Kudos
Message 5 of 73
(5,783 Views)

gratian.crisan ha scritto:

However before you jump through all those hoops can you provide a bit more details about the touchscreen you are trying to use? A lot of them work with the generic driver already present in the kernel.

The output from running the following commands in a console would be helpful in diagnosing the problem (make sure you run these with the touch screen plugged in and Embedded UI enabled):

  • dmesg
  • cat /proc/bus/input/devices
  • xinput --list

Also can you post the following log files:

  • /var/log/Xorg.0.log
  • /var/log/Xsession.log

Hi Gratian

I'm using an usb touchscreen working with eGalax driver.

The problem I've notice on my touch screen is that the tapping doesn't work properly. In particular I'm able to move the pointer on the screen but not to generate an event by tapping on the monitor (i.e. the closing of a windows).

By using the EVTEST command I've seen that the EV_KEY>BTN_TOUCH is always 1 after the firs tap, even is I remove my finger from the screen. Below the corresponding line:

Event: time 1314106977.313482, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1

attached the log files as request.

best

M

0 Kudos
Message 6 of 73
(5,783 Views)

I am not sure exactly what the problem is. We are trying to track down an eGalax based touchscreen to reproduce it. Searching online there seems to be a fair amount of people that have run into problems with eGalax touchscreens on Linux. Apparently there are some with the same USB id but different quirks.

This section in the Xlog.log you've posted looks suspicious (emphasis mine):

[1112004.089] (II) Using input driver 'evdev' for 'eGalax Inc. USB TouchController'

[1112004.089] (**) eGalax Inc. USB TouchController: always reports core events

[1112004.089] (**) evdev: eGalax Inc. USB TouchController: Device: "/dev/input/event6"

[1112004.090] (--) evdev: eGalax Inc. USB TouchController: Vendor 0xeef Product 0x1

[1112004.090] (--) evdev: eGalax Inc. USB TouchController: Found absolute axes

[1112004.090] (--) evdev: eGalax Inc. USB TouchController: Found absolute multitouch axes

[1112004.090] (II) evdev: eGalax Inc. USB TouchController: No buttons found, faking one.

Here is another thing to try: it appears that due to a quirk/workaround the touchscreen shows up as two devices "eGalax Inc. USB TouchController Pen" and "eGalax Inc. USB TouchController". Some people have had luck with disabling one of them.

To test on vs. the other you can run (in a terminal window):

xinput test "eGalax Inc. USB TouchController Pen"

xinput test "eGalax Inc. USB TouchController"

To disable one of them:

xinput disable <device_name>

If the experiment works there are better/more permanent ways to disable one of the devices but this should at least hopefully give us a clue.

0 Kudos
Message 7 of 73
(5,783 Views)

To test on vs. the other you can run (in a terminal window):

xinput test "eGalax Inc. USB TouchController Pen"

xinput test "eGalax Inc. USB TouchController"

To disable one of them:

xinput disable <device_name>

I tried to unable both the devices alternatively but nothing seems to change. For both devices xinput test do not produces any value. With the Controller Pen no event with EVTESToccurs. The touchscreen behavior is the same and the EV_KEY>BTN_TOUCH is always high.

0 Kudos
Message 8 of 73
(5,783 Views)

The eGalax driver need HIDRAW module to work properly. I've tried to complile it in the same way of the uinput module but the compilation, in this case, doesn't work. Is the module still present on lrt and I have just to activate? Egalax suggest to patch the kernel to set

CONFIG_HIDRAW=y

but I don't know how to patch the kernel. Can you help me?

regards

Marco

0 Kudos
Message 9 of 73
(5,783 Views)

The NI kernel on github already has support for HIDRAW, it is just not enabled by default. The egalax instructions are probably outdated since HIDRAW is now present in the mainline upstream kernel and it doesn't require patching.

Follow the instructions on how to rebuild the kernel with the additional step of changing the configuration to enable CONFIG_HIDRAW:

make menuconfig

"Device Drivers" ---> "HID support" ---> "/dev/hidraw raw HID device support"

0 Kudos
Message 10 of 73
(5,783 Views)