On Wed, Jan 16, 2008 at 05:21:00PM +0100, Robert Millan wrote:
> On Wed, Jan 16, 2008 at 02:46:41PM +0100, Robert Millan wrote:
> >
> > See attached patch.
> >
> > I don't like the way I had to hook initialisation in console.c, but solving
> > this properly would require some redesign (converting
On Wed, Jan 16, 2008 at 02:46:41PM +0100, Robert Millan wrote:
>
> See attached patch.
>
> I don't like the way I had to hook initialisation in console.c, but solving
> this properly would require some redesign (converting at_keyboard to a
> module, and adding abstraction to handle input and outp
See attached patch.
I don't like the way I had to hook initialisation in console.c, but solving
this properly would require some redesign (converting at_keyboard to a
module, and adding abstraction to handle input and output separately, etc).
But for now I think it's a valid compromise. I'll wa
On Tue, Jan 15, 2008 at 06:36:40PM +, Patrick Georgi wrote:
> Am Tue, 15 Jan 2008 19:06:25 +0100 schrieb Robert Millan:
> > Is there a way to reproduce this problem without specific hardware?
> > (with qemu or so)
> qemu 0.9.0 exhibits this issue here (using coreboot v2 and grub2-cvs).
> the
Am Tue, 15 Jan 2008 19:06:25 +0100 schrieb Robert Millan:
> Is there a way to reproduce this problem without specific hardware?
> (with qemu or so)
qemu 0.9.0 exhibits this issue here (using coreboot v2 and grub2-cvs).
the keys "1","2","3" lead to "u","a","l" because of table mismatch.
Regards,
On Sat, Jan 12, 2008 at 05:53:42PM +, Patrick Georgi wrote:
> Hi,
>
> second installement of my mini-series:
>
> The AT keyboard driver assumes that the keyboard is set to scancode set
> #1. It seems like many keyboards use set #2 (or even #3) by default now,
> and some 8042-emulating chips
