From: Koen Kooi <koen@dominion.thruhere.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: kbd and console-tools collision when using systemd
Date: Wed, 25 May 2011 08:42:21 +0200 [thread overview]
Message-ID: <iri8ce$acf$1@dough.gmane.org> (raw)
In-Reply-To: <AEF4F94AE6BD724F91B503AC1AFED2392C5E8391CF@STOEXMBXC03.domain01.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 25-05-11 08:00, Anders Darander wrote:
> We have recently switched our local distro to use systemd for the
> init-process. This works fine for our HW-target (apart from some
> non-optimal configuration, but that is something we're looking into).
> Our HW-target is based on the at91sam9g20.
That's good to hear!
> However, sometime later, we tried to rebuild our distro for qemuarm,
> to ease the work on some of the systemd configuration. Qemuarm (just
> as any other Qemu-target) adds keyboard to the machine-features, and
> task-boot.bb translates this into the inclusion of the keymaps
> package, which in turns draws in console-tools. This is where we are
> getting problems.
>
> Local distro uses task-boot.bb Qemu -> keymps -> RDEPENDS
> console-tools Systemd -> RRECOMMENDS kbd
>
> This leads to lots of clashes with e.g. usr/bin/dumpkeys,
> usr/bin/unicode_stop etc. Currently we have solved this by using a
> local copy of task-boot.bb in one of our layers, which lets the
> machine feature keyboard include kbd-keymaps instead of keymaps.
>
> Is there some better/simpler way (maintainence wise) to solve the
> problem? Or is the local task-boot.bb the best way to handle it?
> (It's always better to try to reduce the amount of local copies, to
> be able to benefit from the community, and to easier contribute
> back).
You can work on this problem on two fronts:
1) disable the vconsole service in systemd
2) switch task-boot to kbd
Option 1) is avoiding the real problem, but it's nice to have anyway,
since "most" of the OE platforms work well enough with fbcon to not need
fancy keymaps and fonts.
I briefly looked at kbd vs console-tools during systemd bringup and it
seems that kbd is the best long term answer.
Systemd v28 will also drop the dependency on hwclock, so your system can
be even smaller :)
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFN3KTNMkyGM64RGpERAn5jAJwL4INAEkw+DiHlMdREd5X9F3V2FQCfYwy4
czetFb/X9AUyC4ADzCyfHJM=
=Wn8e
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-05-25 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 6:00 kbd and console-tools collision when using systemd Anders Darander
2011-05-25 6:42 ` Koen Kooi [this message]
2011-05-25 14:05 ` Anders Darander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='iri8ce$acf$1@dough.gmane.org' \
--to=koen@dominion.thruhere.net \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.