weston and hardware keyboard

[Marc Chalain]

Hello,
One problem in embedded world is that people want the same thing with a PC.
Two solutions are available :
 - first we create from scratch every things. Then the software works fine
on the target but it's the "wild west"... :-) and it's bad for the
innovation.
 - second we use libraries from PC world and we have computer-phones
(smartphones have 5 years old, now), and we return to the "wild west" for a
lot of projects (some time big projects) with small target.
The embedded world has to continue in "wild west" mode because many
important projects think in PC mode. The Linux kernel project and the wild
west try to find a solution (Linaro as example), but for the rest anything
isn't done. In my opinion it's surprising, because the biggest market of
Linux is the embedded wold ( the "wild west" ). In embedded software the
main display server is ... none (perhaps surface-flinger with android but
android is farer and farer to the embedded world).
Wayland could replace the direct use of the frame buffer, but for that the
CORE of wayland has to stay the smallest.
In my opinion, the features have to be optionals, to keep a small footprint
and a fast integration if it's needed.
libxkbcommon is feature, and should stay out side the core of wayland and
weston. After if clients need a complete support of PC keyboard, they can
use libxkbcommon, it's normal to find it inside "clients" directory of
weston.
Best regards,
Marc.


2013/6/18 Kristian Høgsberg <krh at bitplanet.net>

> On Tue, Jun 18, 2013 at 4:15 AM, Marc Chalain <marc.chalain at gmail.com>
> wrote:
> > Hello,
> > linux/input.h gives numbers of key definitions. The keymap is only useful
> > for PC keyboard when only the layout change from one country to an
> other. On
> > device we have : on/off, softkey1, softkey2, 12 keys for the keypad in
> some
> > cases, home, back... The key codes are hard coded inside the kernel.
> When we
> > add a keymap, we add codes, and time of treatment, and remove resources.
> On
> > some devices we have only 128Mb of RAM, we can keep a big table in memory
> > just to change KEY_LEFT to XKB_KEY_Left.
> > An other reason to disabling the keymap it's for sillicium founder. They
> > have to provide the backend for the GPU. They have not enough time to
> manage
> > a complete keyboard that the customer will change immediately. When we
> build
> > a BSP for a new board, we have to build the minimum of softwares, like
> that
> > we can develop with the most recent version of the kernel or the graphic
> > libraries.
> > Regards,
> > Marc.
>
> It sounds like a valid use case to me.  I always intended for wayland
> to be useful without the full complexity of XKB, if you're not
> supporting pc-style, international keyboards.  So for a device with a
> small key panel, a set-top box, a car dash board etc, I think not
> using xkb is perfectly fine.  However as soon as there's a usb port
> and you support plugging in real keyboards, XKB is a requirement.
>
> Some of the confusion in the past that Daniel is more about mixing up
> XKB and core X keyboard semantics.  In case of wayland we have a
> pretty clear distinction - either you deal with keycodes (as per
> linux/input.h) only and don't support pc-style keyboards, of you pull
> in xkbcommon and can then translate key codes to keysyms.
>
> Kristian
>
> >
> >
> > 2013/6/18 Michael Hasselmann <michaelh at openismus.com>
> >>
> >> On Mon, 2013-06-17 at 18:08 +0200, Marc Chalain wrote:
> >> > Hello,
> >>
> >>
> >> > My first observation is we need a PC keyboard support at the end
> >> > ( often a virtual keyboard).
> >>
> >> There's an input method procotol that we intended to use for virtual
> >> keyboards. Try weston's clients/editor.c together with the example
> >> keyboard. You can plug in your own by changing [input-method] in
> >> weston.ini for instance.
> >>
> >> Sending key events should be the exception when using a virtual
> >> keyboard. Instead, we rely on input method events to input text. But
> >> even then clients will have to parse those rare key events.
> >>
> >> ciao Michael
> >>
> >>
> >
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130619/1042277a/attachment.html>