Re: NetBSD on tablets?

[Scrap Happy <Scrap%GMX.com@localhost>]

Hi Pierre,

On 7/27/2012 7:48 PM, Pierre Pronchery wrote:
> Hi there,
>
> On Thu, 26 Jul 2012 12:08:37 -0700, Scrap Happy wrote:
> > I assume this is sheer fantasy, but has any work been done on porting
> > NetBSD to any of the "tablets" available?
>
> Yes! I've been improving the DeforaOS desktop environment for tablets
> lately (on NetBSD), and even won an award doing so (the AFULTab contest).
> I was using the WeTab as hardware platform (x86-based, very much like the
> ExoPC for instance).
>
> The documentation submitted for this contest is there:
> http://www.duekin.com/downloads/papers/WeTab%20Freedom%20Report.pdf
>
> On the NetBSD side:
> - uts(4) driver
> - xf86-input-mouse was patched to play well with uts(4)
> - some pending patches to wsconsctl(8) (calibration...)
>
> DeforaOS itself is found at http://www.defora.org/. The website isn't
> great but I'm working on it. The relevant parts are packaged in pkgsrc-wip
> anyway:
> wip/deforaos-*

I (personally) am really only interested in the (NetBSD) kernel
and drivers required to support the underlying hardware devices.
Pretty much everything above that (in my case) is unique.

OTOH, I assume that others -- given a working kernel -- could
port whichever aspects of the application layer seemed appropriate
to their applications.

(I.e., I don't assume folks necessarily want a "NetBSD tablet"
but, rather, "NetBSD running on a tablet form factor")

> > If not, is this due to:
> > - lack of interest - lack of personnel - lack of documentation - lack of
> > "other" resources
>
> Well, I'd love to have more testers, documentation, etc on this work. Or
> marketing even.
>
> > I.e., what (realistically) could be done to facilitate this sort of
> > activity?
>
> I'd say, hardware support would be one of the first things to extend.
> There's a number of ARM-based tablets and smartphones which can be
> "easily" supported, like Nokia's N900 for instance (see also the zaurus
> port). It's a matter of availability of the hardware, and then time and
> motivation to get it ported. Only then it does make more sense and more
> practical to work on the userland part.

(sigh)  In my case, it looks like the options are to move my
applications to run under Android or move to proprietary
hardware -- i.e., spend the money supporting someone else's OS
or your own "custom" hardware... "No Free Lunch".

Good luck in your efforts!
--don