About the keyboard device

[Programmingkid]

Can a keyboard node word be accessed in OpenBIOS? If so, how?

[Tarl Neustaedter]

On 2012-Nov-2 12:49 , Programmingkid wrote:
> Can a keyboard node word be accessed in OpenBIOS? If so, how?

In general, any device method call be called via:

( $device-path) open-dev ( ihandle | 0 )

then (repeat as needed):

( ... $method-name ihandle ) $call-method ( ??? )

When you're done,

( ihandle ) close-dev

In the case of keyboard, since it is always an open and active device, 
make sure you aren't doing something that will foul up the console driver.

[Programmingkid]

On Nov 2, 2012, at 12:55 PM, Tarl Neustaedter wrote:
> On 2012-Nov-2 12:49 , Programmingkid wrote:
> > Can a keyboard node word be accessed in OpenBIOS? If so, how?
>
> In general, any device method call be called via:
>
> ( $device-path) open-dev ( ihandle | 0 )
>
> then (repeat as needed):
>
> ( ... $method-name ihandle ) $call-method ( ??? )
>
> When you're done,
>
> ( ihandle ) close-dev
>
> In the case of keyboard, since it is always an open and active device, make sure you aren't doing something that will foul up the console driver.

How do I obtain the ihandle for the keyboard? I tried " keyboard" open-dev, but that only returns zero.

[Tarl Neustaedter]

On 2012-Nov-2 13:05 , Programmingkid wrote:
> How do I obtain the ihandle for the keyboard? I tried " keyboard" open-dev, but that only returns zero.

That means the open failed.

Make sure your device-path is correct, and if you are sure you have that 
right, you'll have to walk the tree to find out where the open failed.

E.g., on the system I'm currently debugging on, there is a keyboard at:

/pci@340/pci@1/pci@0/pci@3/usb@0/hub@7/keyboard@1

When you call open-dev, it walks through the above path opening each of 
the parents, and if any of the opens fails, the whole open-dev fails. 
E.g., it performs opens on the below list:

/pci@340
/pci@340/pci@1
/pci@340/pci@1/pci@0
/pci@340/pci@1/pci@0/pci@3
/pci@340/pci@1/pci@0/pci@3/usb@0
/pci@340/pci@1/pci@0/pci@3/usb@0/hub@7
/pci@340/pci@1/pci@0/pci@3/usb@0/hub@7/keyboard@1

If you can figure out which node in your particular system is failing, 
you can debug the "open" method to find out why the open is refusing. I 
suspect either you have the wrong path or the keyboard itself is saying 
that it won't open a second time (it's already opened by the console 
driver).

In your case, I'd go to the keyboard node and debug the open method 
there and re-try the open-dev. If you don't even get into the debugger, 
you aren't reaching the keyboard node. If you do, you can step through 
it and find out why it's refusing.