On 03/27/2016 09:11 PM, Clément VUCHENER wrote:
Check the value of errno just after the failed call (and use strerror
to get a nice error message).
See the following output of my test program
UI_FF_UPLOAD start
UI_FF_UPLOAD middle
first ioctl failed -1 Inappropriate ioctl for device
second ioctl failed -1 Inappropriate ioctl for device
UI_FF_UPLOAD end
You also need to check the event code, it must be UI_FF_UPLOAD.
else if (event.type == EV_UINPUT) {
printf("EV_UINPUT %d\n", event.code);
if (event.code == UI_FF_UPLOAD) {
printf("UI_FF_UPLOAD start\n");
struct uinput_ff_upload upload;
memset(&upload, 0, sizeof(upload));
upload.request_id = event.value;
printf("UI_FF_UPLOAD middle\n");
int ret;
ret = ioctl(args->fduinput, UI_BEGIN_FF_UPLOAD, &upload);
if (ret < 0) {
printf("first ioctl failed %d %s\n", ret, strerror(errno));
}
// Remember ID and motor values for playback
if (upload.effect.type == FF_RUMBLE) {
effect_id = upload.effect.id;
strong = upload.effect.u.rumble.strong_magnitude;
weak = upload.effect.u.rumble.weak_magnitude;
printf("Effect uploaded\n");
}
ret = ioctl(args->fduinput, UI_END_FF_UPLOAD, &upload);
if (ret < 0) {
printf("second ioctl failed %d %s\n", ret, strerror(errno));
}
printf("UI_FF_UPLOAD end\n");
}
else if (event.code == UI_FF_ERASE) {
struct uinput_ff_erase erase;
memset(&erase, 0, sizeof(erase));
erase.request_id = event.value;
// Doesn't make sense to actually erase something...
ioctl(args->fduinput, UI_BEGIN_FF_ERASE, &erase);
ioctl(args->fduinput, UI_END_FF_ERASE, &erase);
printf("Event erased\n");
}
}
I report that my device only supports one effect at once. My idea was
that I maybe try to get ff-memless connected to uinput at a later time
to make it emulate the common "memless configuration" used by the kernel
and operate my one-effect-rumble-only device.
The above code works well as long as nothing was sent out to the open
uinput file descriptor.
As soon as I press a button on my USB input device, it "wakes up" and
sends out information even if no button is pressed. This information is
also forwarded to uinput, so from this point on there is a regular
information stream from my code to the uinput module.
Maybe I have to add that I run dual-threaded. The above code is from my
"reception thread". The sending runs on a separate "sending thread".
Did I currently find out that uinput is not multithread-safe?
Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
