On 9/20/07, Sander van Rossen <[EMAIL PROTECTED]> wrote:
>
> On 9/19/07, Bruce <[EMAIL PROTECTED]> wrote:
> > Sander:
> >
> > In your glorious fixings of the kernel, you modified
> /ADC/X86/Keyboard.cs,
> > such that SetLEDs() no longer accepts the three boolean parameters.
>
> Oh i might have done that while trying to figure out why my leds
> weren't changing when pressing the capslock.. i ran out of time
> figuring out why this happened..
> i guess i should've changed it back before committing
Well, it was just halfway between two viable options.
> Whilst I definitely identify with using state management to privately
> > control which LEDs are illuminated, the /ADC/Keyboard.cs file contains a
> > stub that causes an expectation of the "old" SetLEDs(bool,bool,bool) in
> the
> > X86 layer. (I noticed, because the AOT is belching since the methods
> don't
> > match.) So, out of such, arises a couple questions.
>
> I'm suprised the SetLed function is a stub actually
Well, if all keyboards have those three LEDs... but of course, in the real
world, they don't. At least, some keyboards, I'm sure, have extra LEDs. We
can remove the stub.
> Do we want this stub publicly exposed at all? Do we need to manually toy
> > with these lights? Or should we just privately toggle them on and off as
> > their respective buttons are pressed?
>
> Well i think our keyboard mapping should have multiple states that can
> be toggled and a keymap for each state.. (just like we have default
> and shifted now)
> Because shift is not enough, we also have numlock.. and some laptop
> keyboards also have some key special key with which you can make
> special key combinations etc.
Oh, and I perfectly agree. I was talking more about whether or not we want
other parts of the kernel to tinker and flicker with those LEDs...
> I can commit a change either way, I was just rather disappointed to see
> the
> > AOT crash after updating my local working copy hoping to see your fixes
> in
> > action... *sniffle*
>
> It crashed? That's odd, it didn't here :(
> Sorry about that, i hope you weren't too upset.. ;)
*sniffle* Well, since the SetLEDs() stub didn't match what was in the X86
layer, it kinda didn't like that. "Crash" is an exaggeration. But then it
really *did* crash, because, according to Chriss, some Asm.XXX stubs were
being called incorrectly from some code, somewhere, that didn't use the
right parameter types - so Chriss added some more descriptive safeguards
against it.
But now interrupts aren't firing. At all. This time yeserday, before the
keymap fixings, it worked. And at some point, between all your commits, the
couple Chriss made, and the couple I made, interrupts stopped working. I
have no idea what is going on - I've scoured through the diffs, and nothing
seems to be to blame.
Oh well, just more work for tomorrow...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
