| Message ID | 20170128190100.GA32332@dtor-ws (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Jan 28, 2017 at 11:01:00AM -0800, Dmitry Torokhov wrote: > Hi Raphael, > > On Sun, Dec 18, 2016 at 03:20:50PM -0500, Raphael Assenat wrote: > > Postpone axis initialization to the first open instead of doing it once > > in joydev_connect. This is to make sure the generated startup events > > are representative of the current joystick state rather than what > > it was when joydev_connect() was called, potentially much earlier. > > > > This solves issues with joystick driven menus that start scrolling > > up each time they are started, until the user moves the joystick to > > generate events. In emulator menu setups where the menu program is > > restarted every time the game exits, the repeated need to move the > > joystick to stop the unintended scrolling gets old rather quickly... > > > > Unless I misunderstood the intent of JS_EVENT_INIT, I think the startup > > events should reflect the current state of the joystick. Please consider > > applying if it makes sense. > > Sorry for the delay and what you are saying certainly makes sense. > Unfortunately with the patch as is we end up re-initializing calibration > coefficients every time user opens device (assuming that there is only > one user of joystick device at a time), whereas before one could have a > small utility calibrating the joystick, and then go on to using it with > some other application (game). How about we keep most of the > initialization in connect() and only populate axis data in open(), like > below? Thinking about it some more, do we really want to fetch current state of joystick and not start with "rest" state? If joystick is actively generating events then it doe snot matter, but if it is resting and has not generated any events yet, then axis values will be at 0, which, if axis range is [0-1024], will translate to -32767. Maybe we should start all clients with JS_CORR_BROKEN as: val = (input_abs_get_max(dev, i) + input_abs_get_min(dev, i)) / 2; joydev->abs[i] = joydev_correct(val, &joydev->corr[i]); What do you think? Thanks.
Hello Dmitry, On Tue, Jan 31, 2017 at 05:44:49PM -0800, Dmitry Torokhov wrote: > On Sat, Jan 28, 2017 at 11:01:00AM -0800, Dmitry Torokhov wrote: > > Hi Raphael, > > > > On Sun, Dec 18, 2016 at 03:20:50PM -0500, Raphael Assenat wrote: > > > Postpone axis initialization to the first open instead of doing it once > > > in joydev_connect. This is to make sure the generated startup events > > > are representative of the current joystick state rather than what > > > it was when joydev_connect() was called, potentially much earlier. > > > > > > This solves issues with joystick driven menus that start scrolling > > > up each time they are started, until the user moves the joystick to > > > generate events. In emulator menu setups where the menu program is > > > restarted every time the game exits, the repeated need to move the > > > joystick to stop the unintended scrolling gets old rather quickly... > > > > > > Unless I misunderstood the intent of JS_EVENT_INIT, I think the startup > > > events should reflect the current state of the joystick. Please consider > > > applying if it makes sense. > > > > Sorry for the delay and what you are saying certainly makes sense. > > Unfortunately with the patch as is we end up re-initializing calibration > > coefficients every time user opens device (assuming that there is only > > one user of joystick device at a time), whereas before one could have a > > small utility calibrating the joystick, and then go on to using it with > > some other application (game). How about we keep most of the > > initialization in connect() and only populate axis data in open(), like > > below? > > Thinking about it some more, do we really want to fetch current state of > joystick and not start with "rest" state? Both approaches have merits, and in the context of my original issue, they both work perfectly. But I think that returning the current value might be more correct as there could be situations where it is needed. I'm thinking about unusual/custom/homemade controls with potentiometers on a panel where the initial value should be effective right from the start. But one could argue that this is not a joystick anymore and should be using evdev (or even hidraw) instead. (There is a similar issue with evdev by the way. For HID joysticks, the current value of abs axes is zero until events are generated, but for a different reason. More on this below.) > If joystick is actively generating events then it doe snot matter, but > if it is resting and has not generated any events yet, then axis values > will be at 0, which, if axis range is [0-1024], will translate to > -32767. Indeed, it won't return a centered value initially, but HID joysticks should generate events at startup (Through the use of HID Get_Report requests). However this feature seems broken at the moment. While the get_report requests are properly sent to the HID device, the answers arrive at a time when they cannot be processed and get dropped. I created two patches last year to workaround this issue, but I'm not sure if they are correct (I re-order things and am not sure if there are implications I don't see). I planned to rebase them (if necessary) and post them here soon, but for now here are the originals: http://www.raphnet-tech.com/support/retropie/usbhid_iostart.diff http://www.raphnet-tech.com/support/retropie/usbhid_start_before_connect.diff > Maybe we should start all clients with JS_CORR_BROKEN as: > > val = (input_abs_get_max(dev, i) + input_abs_get_min(dev, i)) / 2; > joydev->abs[i] = joydev_correct(val, &joydev->corr[i]); > > What do you think? I'm comfortable with both suggestions, however I feel that returning the current value is better, even though it would not be perfect until a solution to the other issue I mentioned is implemented. Best regards, Raphaël Assénat -- 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
On Thu, Feb 02, 2017 at 11:22:29PM -0500, Raphael Assenat wrote: > Hello Dmitry, > > On Tue, Jan 31, 2017 at 05:44:49PM -0800, Dmitry Torokhov wrote: > > On Sat, Jan 28, 2017 at 11:01:00AM -0800, Dmitry Torokhov wrote: > > > Hi Raphael, > > > > > > On Sun, Dec 18, 2016 at 03:20:50PM -0500, Raphael Assenat wrote: > > > > Postpone axis initialization to the first open instead of doing it once > > > > in joydev_connect. This is to make sure the generated startup events > > > > are representative of the current joystick state rather than what > > > > it was when joydev_connect() was called, potentially much earlier. > > > > > > > > This solves issues with joystick driven menus that start scrolling > > > > up each time they are started, until the user moves the joystick to > > > > generate events. In emulator menu setups where the menu program is > > > > restarted every time the game exits, the repeated need to move the > > > > joystick to stop the unintended scrolling gets old rather quickly... > > > > > > > > Unless I misunderstood the intent of JS_EVENT_INIT, I think the startup > > > > events should reflect the current state of the joystick. Please consider > > > > applying if it makes sense. > > > > > > Sorry for the delay and what you are saying certainly makes sense. > > > Unfortunately with the patch as is we end up re-initializing calibration > > > coefficients every time user opens device (assuming that there is only > > > one user of joystick device at a time), whereas before one could have a > > > small utility calibrating the joystick, and then go on to using it with > > > some other application (game). How about we keep most of the > > > initialization in connect() and only populate axis data in open(), like > > > below? > > > > Thinking about it some more, do we really want to fetch current state of > > joystick and not start with "rest" state? > Both approaches have merits, and in the context of my original > issue, they both work perfectly. > > But I think that returning the current value might be more correct as there > could be situations where it is needed. I'm thinking about unusual/custom/homemade > controls with potentiometers on a panel where the initial value should be > effective right from the start. But one could argue that this is not a joystick > anymore and should be using evdev (or even hidraw) instead. > > (There is a similar issue with evdev by the way. For HID joysticks, the current > value of abs axes is zero until events are generated, but for a different > reason. More on this below.) > > > If joystick is actively generating events then it doe snot matter, but > > if it is resting and has not generated any events yet, then axis values > > will be at 0, which, if axis range is [0-1024], will translate to > > -32767. > Indeed, it won't return a centered value initially, but HID joysticks > should generate events at startup (Through the use of HID Get_Report requests). > > However this feature seems broken at the moment. While the get_report requests > are properly sent to the HID device, the answers arrive at a time when they > cannot be processed and get dropped. > > I created two patches last year to workaround this issue, but I'm not sure if they > are correct (I re-order things and am not sure if there are implications I don't > see). I planned to rebase them (if necessary) and post them here soon, but for now > here are the originals: > http://www.raphnet-tech.com/support/retropie/usbhid_iostart.diff > http://www.raphnet-tech.com/support/retropie/usbhid_start_before_connect.diff > > > Maybe we should start all clients with JS_CORR_BROKEN as: > > > > val = (input_abs_get_max(dev, i) + input_abs_get_min(dev, i)) / 2; > > joydev->abs[i] = joydev_correct(val, &joydev->corr[i]); > > > > What do you think? > I'm comfortable with both suggestions, however I feel that returning the current > value is better, even though it would not be perfect until a solution to the other > issue I mentioned is implemented. OK, let's start with the current one and we may revisit it later. Thanks.
diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c index abd18f31b24f..db5e290e897e 100644 --- a/drivers/input/joydev.c +++ b/drivers/input/joydev.c @@ -187,6 +187,17 @@ static void joydev_detach_client(struct joydev *joydev, synchronize_rcu(); } +static void joydev_refresh_state(struct joydev *joydev) +{ + struct input_dev *dev = joydev->handle.dev; + int i, val; + + for (i = 0; i < joydev->nabs; i++) { + val = input_abs_get_val(dev, joydev->abspam[i]); + joydev->abs[i] = joydev_correct(val, &joydev->corr[i]); + } +} + static int joydev_open_device(struct joydev *joydev) { int retval; @@ -201,6 +212,8 @@ static int joydev_open_device(struct joydev *joydev) retval = input_open_device(&joydev->handle); if (retval) joydev->open--; + else + joydev_refresh_state(joydev); } mutex_unlock(&joydev->mutex); @@ -872,7 +885,6 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev, j = joydev->abspam[i]; if (input_abs_get_max(dev, j) == input_abs_get_min(dev, j)) { joydev->corr[i].type = JS_CORR_NONE; - joydev->abs[i] = input_abs_get_val(dev, j); continue; } joydev->corr[i].type = JS_CORR_BROKEN; @@ -887,10 +899,6 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev, if (t) { joydev->corr[i].coef[2] = (1 << 29) / t; joydev->corr[i].coef[3] = (1 << 29) / t; - - joydev->abs[i] = - joydev_correct(input_abs_get_val(dev, j), - joydev->corr + i); } }