[Arm-netbook] IC for analog and digital buttons (EOMA-68)

[Miguel Garcia]

I've been thinking about this.

There are instances where I might be interested in installing an OS
optimized for consoles (such as OpenDingux in JZ4775 like GCW-Zero).

I think it would be interesting to sell this card with this OS
installed. But this would only interest in a console (not in tablets
or similar), so it makes no sense a EOMA-68 with this software.

Could we buy you the EOMA-68 that interest us, rename it (for example
TOTOTO), install on it our software and sell only for the console?

The console will be compatible with EOMA-68 and TOTOTO. But other
EOMA-68 chasis won't be compatible with TOTOTO.

Then, geeks users can install the OS/software of EOMA-68 in TOTOTO and
convert the EOMA-68 in a TOTOTO card. Or install the OS/software of
TOTOTO in EOMA-68 and convert the TOTOTO in a EOMA-68 card.

2014-08-11 16:46 GMT+02:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
> On Mon, Aug 11, 2014 at 3:26 PM, Miguel Garcia <gacuest at gmail.com> wrote:
>> I have a question about the EOMA-68.
>>
>> If you (or someone else) manufactures and sells its own EOMA-68, how
>> it will work on the console?
>>
>> Let me explain. I suppose that the EOMA-68 for the console need
>> special drivers for controls and STM32F. Possibly someone buy a
>> EOMA-68 in a store and that EOMA-68 does not have these drivers. Can
>> he not use that EOMA-68 on the console?
>
>  interesting and relevant question!
>
>  interesting because there is still quite a bit of work that needs to be done.
>
>  addressing the drivers:
>
>  a) there needs to be (will be) an "official" kernel area for eoma68
> cards.  pulling random kernels and software is going to "work" for a
> given value of "work" but it won't really be properly eoma68 compliant
> unless people use the proper kernels
>
>  b) so for example the drivers needed for the console will be in that
> "official" area.
>
>  c) part of that area involves the device-tree "merging" code (that
> will need to be written), so that the CPU Cards can dynamically detect
> what they're plugged into, load the Device-Tree fragment out of the
> EEPROM and go from there.
>
>  addressing the software:
>
>  a card out-of-the-box (3rd party) isn't exactly going to have the
> games or other apps on it, is it! :)  so, it would "work"... but it
> would work only with what the OS software could find: screen, USB-HID
> devices, USB Audio and so on.  soooo.... in theeorryyy, with the
> STM32F publishing "buttons" via a USB-HID, and publishing the analog
> joystick again as a USB mouse, in theeeoorrryyy "Random OS Mk VII"
> *might* actually work.
>
> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk