On Fri, Aug 15, 2008 at 05:35:15PM -0700, <email address hidden> wrote:
> --- Comment #4 from Sergey V. Udaltsov <email address hidden> 2008-08-15 17:35:14 PST ---
> Yes I know about fedora. And I am not terribly happy with that. What I can
> propose (for linuxes only - dirty hack!) is
> 1. Optional. Adding abnt2 section to keycodes/evdev - with missing keycodes. I
> am not sure what is the status of the keycode KPPT in evdev.
> 2. patching rules/base in order to use evdev keycodes wherever possible. The
> section would look like:
This is why I was suggesting different rules. Even with evdev, you
still have some variance between models, and your options are
essentially to have your models as evdev, evdev_abnt2, etc, or to create
a new ruleset called evdev, and let the model field actually refer to
models again.
evdev is here to stay, so we're going to have to deal with it somehow.
On Fri, Aug 15, 2008 at 05:35:15PM -0700, <email address hidden> wrote:
> --- Comment #4 from Sergey V. Udaltsov <email address hidden> 2008-08-15 17:35:14 PST ---
> Yes I know about fedora. And I am not terribly happy with that. What I can
> propose (for linuxes only - dirty hack!) is
> 1. Optional. Adding abnt2 section to keycodes/evdev - with missing keycodes. I
> am not sure what is the status of the keycode KPPT in evdev.
> 2. patching rules/base in order to use evdev keycodes wherever possible. The
> section would look like:
This is why I was suggesting different rules. Even with evdev, you
still have some variance between models, and your options are
essentially to have your models as evdev, evdev_abnt2, etc, or to create
a new ruleset called evdev, and let the model field actually refer to
models again.
evdev is here to stay, so we're going to have to deal with it somehow.