Re: odevice_ipaq, machine IDs and button init

Hello Paul,

Thursday, February 8, 2007, 2:04:12 PM, you wrote:

> Hi there,

> I have found out why I am seeing so many extra buttons in the Button settings
> application on my iPAQs (h3850 & h3970). If you take a look in
> odevice_ipaq.cpp you can see in init() it checks to see if the button model
> ANDed with the device model = the device model, which would be just fine if
> the none of the device models were binary subsets of eachother - except they
> are. When tested in this way, a button defined as being for eg.
> Model_iPAQ_H22xx (0x10007) will be active on Model_iPAQ_H31xx (0x10001),
> Model_iPAQ_H36xx (0x10002), and Model_iPAQ_H38xx (0x10004). This has probably
> been happening for a while but it has started to become more of a problem as
> support for new iPAQs has been added recently.

  Ah, yep, I noticed that too. But as it's just one of bunch problems
I see with ODevice at all, this was shadowed by other problems.

> It seems to me we either need to renumber all of the devices so that only one
> bit in the model mask is set (0x10001, 0x10002, 0x10004, 0x10008...), or we
> come up with another way of associating buttons with multiple models.

  Yep, I guess using bitfields should be a solution for 1.2.3, if we
still could fit iPaq's we currently have there.

  As for real solution, all ODevice subclass set must be completely
rewritten, as it is real crap now. I envision following directions for
that:

1. Proper domain separation. 2.4 vs 2.6 kernels differ from each other
more than devices which use it. So, there must be ODevice24/ODevice26
as direct subclasses of OAbstractMobileDevice, which would capture the
common functionality of kernel interface.

2. Common standards. 2.6 already defines many aspects of hardware
interface, so they will be the same for all devices. And we should
promote standards and best practices for areas it doesn't stipulate,
like button encoding (i.e. it's not OPIE what should bend to different
devices' idiosyncrasies, it's device kernel must adhere to some
spec to be supported, but once they do, support is automagical).

3. Config- and data-drivenness. As some aspects will still be
machine-dependent, it's better to add external config file support
than to encode feature in C++. Preferably, such config would be of teh
form of config database, i.e. mapping from device names to config
sets. Per 2, there should be few of them still, so such config
won't be big.

> Any comments?

> Cheers,
> Paul
> _______________________________________________

-- 
Best regards,
 Paul                            mailto:pmiscml_at_gmail.com