>>> Q. Do we need the ability to switch between split/combined pedals? > I am not sure on this - on the one hand i would love to provide all > options to the user. > On the other hand i am not sure how this could be done. I do not think > it is possible to change the report descriptor of a connected device on > the fly without (not necessarily physically) reconnecting it? > And from my understanding the combined axes are just some kind of legacy > stuff to support really old games which can not handle the separate axes. Can you (someone?) clarify which wheels do not have a command to switch into 'native mode' (which causes a USB ID change) and do these wheels use a unified brake/acc.? Do any wheels have a 'native mode' which stay with the generic USB ID? Wouldn't the device descriptor only be re-written for the new USB ID's in 'native' mode. Note: The Wii wheel does not have a 'native' command/mode, but has a unique ID which is always used. > Is there any reason the switch to native mode should not be done > automatically by the driver? I would prefer to have it working > out-of-the-box instead of having to wait for userspace interaction. > (This could be done by some udev rule(s), but then this would need to be > adopted by all distributions...) > I do not see any point in using the wheel in restricted mode when native > mode is possible... If we force the 'native command' to be issued then we might affect/prevent any 'old game' play. Note 2: At present the re-writing of descriptor is done in 'hid-lg.c' (based on USB ID), whereas we are proposing the 'native' command to be issued by 'hid-lg4ff.c' which might not be complied/enabled. Perhaps disabling/blacklisting 'hid-lg4ff' is a sufficient workaround to get older games working... or a module option of 'no-native' could prevent the command being sent. Also I noticed that the second part of the 'DFP native command', is very similar to a strong spring set to slot 4.... Simon -- 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
