new imon 0xffdc device id theory

[Jarod W. <ja...@wi...>]

So with my device descriptor id-based theory thoroughly crushed, I
have a new thought on how to id different 0xffdc devices.

In comparing the differences between the 0xffdc imon knob and 0xffdc
imon vfd here, There are two notable differences.

First, some background... The 0xffdc devices are horribly inefficient.
They all *constantly* send interrupt service requests, even when they
have not received any IR. When we read from the device, we just get FF
FF FF FF FF FF xx FF from it when there's no IR. This isn't Linux
doing anything wrong either, its that way under Windows too.

So you'll note that I put an xx in the second to last byte of the "no
IR" spew above. This byte is constant for the two devices here, and
constantly different between them. The imon knob always has 21 here,
the imon vfd always has 85 here. Its possible this value is what
SoundGraph's windows driver uses to identify which 0xffdc device its
talking to. But I'd need to see numbers from a few more people's
devices. Getting that info requires either sniffing the usb bus, or
rebuilding the driver to not silently ignore the "no IR" spew. If some
sort of pattern emerges, then I'll need to figure out some way to
capture that during the probe routine to do auto-config.

The second notable difference between init on the knob and vfd is that
the knob *always* has an initial incoming buffer packet of FF FF FF FF
00 6F 21 01, before it starts spewing FF FF FF FF FF FF 21 FF. I'm
curious if anyone else's 0xffdc device has some initial value it sent
-- this should actually get reported in dmesg as an unknown keypress.
This is at least a way I can identify *my* imon knob and take steps to
automatically not set up a /dev/lcd0 with it.

Either way, it seems the probe routine is going to have to grab data
out of the device's buffer prior to setting up the interrupt callback
to make an informed decision about what the device's capabilities are.

Oh, and I'm debating flipping the default display type for the 0xffdc
over to vfd, as all the people I've got data from so far have 0xffdc
vfd devices, haven't heard from a single 0xffdc lcd device owner...
But hopefully, that'll be a moot point if we can figure out what it is
that's actually defining the device type and abilities...

-- 
Jarod Wilson
ja...@wi...