Re: uinput: ioctls for UI_BEGIN_FF_UPLOAD fails (returns -1). How to debug?

[Manuel Reimer <mail+linux-input@m-reimer.de>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html