Alan Cox wrote:
>> 160x43 --- The same as the G15 and MX5000 keyboards. In fact, it takes
>> the
>> same bitmap pattern as the keyboards.
>>
>> 160x43 is small, but some graphics are definitely possible, console/text
>> is certainly possible.
>
> Ultimately it should probably also create a console device of itself, but
> its not something trivial to do and I really wouldn't bother about it
> until it works in current form if ever...
>
> Mind you a keyboard that has the display built in would be really useful
> for poking around server boxes on racks.
>
I have the display as a framebuffer device now (based on fbdefio with the
hid device as the parent).
Do I really need a separate console device or can I just use fbcon?
> I have the display as a framebuffer device now (based on fbdefio with the
> hid device as the parent).
>
> Do I really need a separate console device or can I just use fbcon?
fbcon should do what you want.
ALan
Alan Cox wrote:
>> I have the display as a framebuffer device now (based on fbdefio with
>> the
>> hid device as the parent).
>>
>> Do I really need a separate console device or can I just use fbcon?
>
> fbcon should do what you want.
>
I've been playing with fbcon, but can't get a fbcon console started.
I wrote a little app that uses the framebuffer ioctls to change fbcon's
map. Specifically, the G13 shows up as fb1, and the app basically does
this:
int fd = open("/dev/fb1", O_RDWR);
struct fb_con2fbmap con2fb;
int ret;
if ( fd < 0 ) { printf("Error opening %s\n", DEVICE); return -1; }
con2fb.console = 5;
ioctl(fd, FBIOGET_CON2FBMAP, &con2fb);
printf("Console: %d Framebuffer: %d\n", con2fb.console,
con2fb.framebuffer);
con2fb.framebuffer = 1;
ret = ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);
printf("Succeeded: %d\n", ret);
ioctl(fd, FBIOGET_CON2FBMAP, &con2fb);
printf("Console: %d Framebuffer: %d\n", con2fb.console,
con2fb.framebuffer);
This succeeds and I get:
Console: 5 Framebuffer: 0
Succeeded: 0
Console: 5 Framebuffer: 1
But, when I change to console 5 that's when things die. I never hit any of
my fb_ops callbacks.
The driver can be found here:
http://g13.svn.sourceforge.net/viewvc/g13/driver/trunk/hid-g13.h
http://g13.svn.sourceforge.net/viewvc/g13/driver/trunk/hid-g13.c
This doesn't actually do anything but do a printk (in hex) of the
framebuffer memory.
When I modify the framebuffer through a mmap I don't have any problems,
but when I switch to the console the kernel hangs.
I'm currently recompiling the kernel with FBCONDEBUG defined and I'll test
from there.
Any other suggestions on how to approach this?
Thanks,
---
Rick