From: Manuel Reimer <hidden> Date: 2016-01-17 13:27:44
Hello,
I have an existing uinput driver, which itself sits on an open device
with a blocking read(), waiting for events to come in. Every event is
translated to a key code and then sent to uinput.
My next step would be to pass through force feedback information, but I
don't really understand how I should do this.
As far as I can see, the "uninput device" itself sends events in this
case. But my main loop is already blocked by the "read", I use to get
device events.
I see two possible solutions:
- "Somehow", I should be able to get "blocking read" from two open
devices. As far as I found out, so far, "select" should be the right
command to do this?
- I could start two threads. One blocked by the "device events" and one
by the "uinput events".
Which one would you recommend? Is uinput/ioctl thread safe? Is the
second thread a good idea or is the communication, coming from uinput,
such "low traffic", that it doesn't delay key handling in a relevant way?
Thank you very much in advance
Manuel
From: Elias Vanderstuyft <hidden> Date: 2016-01-17 15:46:13
On Sun, Jan 17, 2016 at 2:27 PM, Manuel Reimer
[off-list ref] wrote:
Hello,
I have an existing uinput driver, which itself sits on an open device with a
blocking read(), waiting for events to come in. Every event is translated to
a key code and then sent to uinput.
My next step would be to pass through force feedback information, but I
don't really understand how I should do this.
From: Elias Vanderstuyft <hidden> Date: 2016-01-17 15:47:22
On Sun, Jan 17, 2016 at 4:46 PM, Elias Vanderstuyft [off-list ref] wrote:
On Sun, Jan 17, 2016 at 2:27 PM, Manuel Reimer
[off-list ref] wrote:
quoted
Hello,
I have an existing uinput driver, which itself sits on an open device with a
blocking read(), waiting for events to come in. Every event is translated to
a key code and then sent to uinput.
My next step would be to pass through force feedback information, but I
don't really understand how I should do this.
Patches are more than welcome! (I'm the author of libsuinput, happy to
see someone actually uses it without python-uinput, but I welcome
patches to python-uinput as well).
--
Tuomas
Tried that and I'm pretty close to giving up...
I've added the following to my uinput init function:
// Set up force feedback parameters
ret = ioctl(fd, UI_SET_EVBIT, EV_FF);
ret = ioctl(fd, UI_SET_FFBIT, FF_PERIODIC);
ret = ioctl(fd, UI_SET_FFBIT, FF_RUMBLE);
ret = ioctl(fd, UI_SET_FFBIT, FF_GAIN);
ret = ioctl(fd, UI_SET_FFBIT, FF_SQUARE);
ret = ioctl(fd, UI_SET_FFBIT, FF_TRIANGLE);
ret = ioctl(fd, UI_SET_FFBIT, FF_SINE);
From my device handling thread, I'm starting a separate thread to
handle the opposite direction of communication. Plan is to do blocking
read from the open uinput device. I open the device with O_RDWR to be
able to read and write. The "rumble thread" starts with:
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
struct input_event event;
while (1) {
ssize_t n = read(args->fduinput, &event, sizeof(event));
printf("n: %d\n", n);
Everything beyond this never executes. The read blocks forever.
And even worse: If the read blocks, my "driver", and all programs
connected to my input device, are deadlocked. No chance to kill them.
And to be honest: After three hours of debugging I'm kind of sick of
rebooting my machine over and over again.
Any chance to get some hint?
Thanks in advance
Manuel
From: Manuel Reimer <hidden> Date: 2016-02-05 20:58:45
Hello,
I just want to add here, that I found the reason for this problem.
It is required that the ff_effects_max field of the uinput_user_dev
struct is set. Without doing this everything just hangs...
Best regards,
Manuel
On 02/05/2016 04:54 PM, Manuel Reimer wrote:
Tried that and I'm pretty close to giving up...
I've added the following to my uinput init function:
// Set up force feedback parameters
ret = ioctl(fd, UI_SET_EVBIT, EV_FF);
ret = ioctl(fd, UI_SET_FFBIT, FF_PERIODIC);
ret = ioctl(fd, UI_SET_FFBIT, FF_RUMBLE);
ret = ioctl(fd, UI_SET_FFBIT, FF_GAIN);
ret = ioctl(fd, UI_SET_FFBIT, FF_SQUARE);
ret = ioctl(fd, UI_SET_FFBIT, FF_TRIANGLE);
ret = ioctl(fd, UI_SET_FFBIT, FF_SINE);
From my device handling thread, I'm starting a separate thread to
handle the opposite direction of communication. Plan is to do blocking
read from the open uinput device. I open the device with O_RDWR to be
able to read and write. The "rumble thread" starts with:
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
struct input_event event;
while (1) {
ssize_t n = read(args->fduinput, &event, sizeof(event));
printf("n: %d\n", n);
Everything beyond this never executes. The read blocks forever.
And even worse: If the read blocks, my "driver", and all programs
connected to my input device, are deadlocked. No chance to kill them.
And to be honest: After three hours of debugging I'm kind of sick of
rebooting my machine over and over again.
Any chance to get some hint?
Thanks in advance
Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Elias Vanderstuyft <hidden> Date: 2016-02-10 21:41:37
On Fri, Feb 5, 2016 at 9:58 PM, Manuel Reimer
[off-list ref] wrote:
Hello,
I just want to add here, that I found the reason for this problem.
It is required that the ff_effects_max field of the uinput_user_dev struct
is set. Without doing this everything just hangs...
From: Manuel Reimer <hidden> Date: 2016-02-15 20:11:44
On 02/10/2016 10:41 PM, Elias Vanderstuyft wrote:
Which kernel version are you using?
The first patch is already in version 4.4.
Currently 4.3.3. Self-built to have a small patch which makes PS4
controller bluetooth binding possible (will be in kernel in version 4.5).
Rumble seems to be a problem with uinput in general. For example it is
pretty easy to create "non-killable" processes if fftest is still
running when the uinput daemon is killed. Not much fun to debug
something like this, so I finally disabled my rumble support.
Glad you got it working now,
Partially but not really solving my problem. Still working on it.
Manuel