<div dir="ltr"><div><div><div><div><div><div><div>Hello,<br></div>One problem in embedded world is that people want the same thing with a PC.<br>Two solutions are available : <br> - 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.<br>
</div> - 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.<br>
</div>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).<br>
</div>Wayland could replace the direct use of the frame buffer, but for that the CORE of wayland has to stay the smallest.<br></div>In my opinion, the features have to be optionals, to keep a small footprint and a fast integration if it's needed.<br>
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.<br>
</div>Best regards,<br></div>Marc.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/18 Kristian Høgsberg <span dir="ltr"><<a href="mailto:krh@bitplanet.net" target="_blank">krh@bitplanet.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jun 18, 2013 at 4:15 AM, Marc Chalain <<a href="mailto:marc.chalain@gmail.com">marc.chalain@gmail.com</a>> wrote:<br>

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