Replacement for hal-setup-keymap

Kay Sievers kay.sievers at vrfy.org
Thu May 7 03:29:54 PDT 2009


On Thu, May 7, 2009 at 11:58, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Kay Sievers [2009-05-06  1:16 +0200]:
>> >  - Would you prefer using input-utils or a copy of the input-kbd
>> >   script in udev-extras?
>>
>> I think, we should put all of that, including the binary, in a subdir
>> in udev-extras, and install the binary in /lib/udev/. Then we are free
>> to change stuff as we need, and don't depend on stuff that might not
>> exist on some systems.
>
> Done. I put the keymaps themselves into /lib/udev/keymaps/ for now
> (instead of /usr/share/udev/keymaps/, as in my first sketch).

Ah, i see. What's the reason for that? Not that I have objections to do that.

> I have the keymap setting tool, build system changes, conversion tool,
> and the first set of converted keymaps ready now.
>
> I tested it on my Dell Latitude, and it's working well.

Nice.

> I wasted half an hour trying to push my git branch to an ssh server
> and finally gave up after I managed to push it to remote, but pulling
> didn't update anything; so I use format-patch for now.

You can run "git gc; git prune" on your repo to get all objects in a
single pack, and then you can just rsync your entire .git directory as
<name>.git to some server. That always works if stuff goes wrong. :)

> Do these look okay so far?

Looks good so far, yes.

> I'll continue keymap conversion in the next days, and will send
> further patches.
>
> BTW, what's necessary to get an account on git.kernel.org,

http://www.kernel.org/faq/#account

Mention, that you want to maintain a part of the device database in
udev, and request a membership in the "hotplug" group. Just put me in
Cc: when you send it, I may need to follow-up to say ok.

> so that I
> could continuously maintain keymaps in my own udev-extras branch
> there, and it's easy for you to pull from that?

You can just use the main udev-extras repo to maintain your stuff
there. It is shared. Just post questionable stuff, or changes to the
build system, or introduced dependencies to the mailing list, but
commit your stuff right away.

Thanks,
Kay


More information about the devkit-devel mailing list