Quirks

[Hans Petter Selasky]

On Friday 11 July 2008, Tino Engel wrote:
> Hi --HPS,
>
> > Hi Tino,
> >
> > Let's focus on getting the USB mass storage problems fixed first.
> > There are plenty of USB Mass Storage IR's in the database.
> >
> > What kind of quirk strategy would you like to apply?
> >
> > If the device fails the Mass Storage test, then switch on all
> > possible quirks ? Which means that the user might have to replug the
> > USB device ?
> >
> > --HPS
>
> Here is a map of what I think would be reasonable:
>
>
> At first there is a file (let's say /etc/ums.conf) which holds the
> configuration of how to approach new devices. The file is delivered
> with reasonable defaults.
>
>
> GLOBAL OPTIONS:
> ===============
> If the option ALL_QUIRKS="YES" is set, a new UMS is approached with
> all quirks. If something fails here, there is pretty much nothing left
> to do.
>
> Also all other quirks can be set on by default:
> Example: Q_NO_SYNC_CACHE="YES" would disable cache syncing for all msc
> devices.
>
> So, now there more sophisticated part:
> In case the all quirks option is not set, 2 cases remain in this model:
>
> CASE 1:
> =======
>
> Case 1 describes the case of a MSC device that hangs up
> after receiving a command it could not be able to handle. It ends in a
> unfixable state, even a bus reset cannot help.
>
> That leads us to the conclusion, the device has to be unplugged in
> order to proceed. The only question is, how to proceed then. Also in
> this case, the was is determined by configuration.
>
> The easiest case would be given by using the option:
> STALLED_ALL_QUIRKS="YES"
>
> Then dmesg would tell to replug the device (and other events would be
> triggered, for whatsoever), and all quirks would be applied for this
> device from there on. The information would be held in /var/db/ums or
> whatever appropriate place.
>
> Additionally one could think about enabling a chained quirk set:
> For example I could set STALLED_Q_NO_SYNC_CACHE="1" and
> STALLED_ALL_QUIRKS="2" which would have the effect, that for this
> specific device, cache syncing would be disabled (quirked) on first
> reconnect, and, if failed, all quirks would be activated on next
> connect. dmesg would properly inform me to replug.
>
> Nice would also be an option STALLED_INTELLIGENCE="YES" which would try
> same order as in case 2.
>
> The successful quirk combination is also stored in /var/db/ums.
>
> In addition, it would be nice to have a vendor/device specific config
> format. (e.g. STALLED_Q_NO_SYNC_CACHE="SAMSUNG,1")
>
> This way would have the advantage that my device runs anyhow without
> kernel recompilation (although i might have to replug a couple of times
> in worst case :-( )
>
> CASE 2:
> =======
> In case 2, the device can recover by a usb reset. There it is a runtime
> issue, if just all quirk permutations can be tested or if a
> configuration similar to case 1 is appropriate. (I assume, we can live
> with the runtime there, since plugging an usb device is not a
> real-time-thing ^^)
> Than we can have a nice logic (from most common to less common quirk
> permutations order)
>
> Here we should definitely have a config file, containing device
> specific quirk information, which can be updated.
>
>
> Anyhow, feedback events (e.g. for graphical connection tools)
> interaction with things like HAL and whatever comes up should be
> considered, so it can be implemented sooner or later...
>
>
> What do you think?

Hi Tino,

I think this should be all automatic. Most users will have no clue what to put 
in those configuration files.

Any others have any opinion about this on the list?

--HPS