On Thu, 2014-04-24 at 12:32 +0200, Michal Malý wrote:
> On Wednesday 23 of April 2014 15:41:03 Oliver Neukum wrote:
> > On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > > static int drff_play(struct input_dev *dev, void *data,
> > >
> > > - struct ff_effect *effect)
> > > + const struct mlnx_effect_command *command)
> > >
> > > {
> > >
> > > struct hid_device *hid = input_get_drvdata(dev);
> > > struct drff_device *drff = data;
> > >
> > > + const struct mlnx_rumble_force *rumble_force =
> > > &command->u.rumble_force;
> > >
> > > int strong, weak;
> > >
> > > - strong = effect->u.rumble.strong_magnitude;
> > > - weak = effect->u.rumble.weak_magnitude;
> > > + strong = rumble_force->strong;
> > > + weak = rumble_force->weak;
> > >
> > > dbg_hid("called with 0x%04x 0x%04x", strong, weak);
> > >
> > > - if (strong || weak) {
> > > - strong = strong * 0xff / 0xffff;
> > > - weak = weak * 0xff / 0xffff;
> > > -
> > > - /* While reverse engineering this device, I found that
> > > when
> > > - this value is set, it causes the strong rumble to
> > > function
> > > - at a near maximum speed, so we'll bypass it. */
> > > - if (weak == 0x0a)
> > > - weak = 0x0b;
> > > -
> > > - drff->report->field[0]->value[0] = 0x51;
> > > - drff->report->field[0]->value[1] = 0x00;
> > > - drff->report->field[0]->value[2] = weak;
> > > - drff->report->field[0]->value[4] = strong;
> > > - hid_hw_request(hid, drff->report, HID_REQ_SET_REPORT);
> > > -
> > > - drff->report->field[0]->value[0] = 0xfa;
> > > - drff->report->field[0]->value[1] = 0xfe;
> > > - } else {
> > > + switch (command->cmd) {
> > > + case MLNX_START_RUMBLE:
> > > + if (strong || weak) {
> > > + strong = strong * 0xff / 0xffff;
> > > + weak = weak * 0xff / 0xffff;
> > > +
> > > + /* While reverse engineering this device, I
> > > found that when
> > > + this value is set, it causes the strong rumble
> > > to function
> > > + at a near maximum speed, so we'll bypass it.
> > > */
> > > + if (weak == 0x0a)
> > > + weak = 0x0b;
> > > +
> > > + drff->report->field[0]->value[0] = 0x51;
> > > + drff->report->field[0]->value[1] = 0x00;
> > > + drff->report->field[0]->value[2] = weak;
> > > + drff->report->field[0]->value[4] = strong;
> >
> > This looks like an endianness bug.
>
> I don't have a big endian machine to check but why would this be an endianness
> issue? We're dealing with values all the time here, not addresses so I'd
> expect the 'weak' and 'strong' values to be truncated if they won't fit into
> byte. Division done beforehand makes sure that the values are within <0; 255>
> range. As far as I can see this is quite common in the HID and Input code. Am
> I missing something here?
Sorry, I thought you were writing to 16bit variables.
Regards
Oliver
--
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
