Re: [uml-devel] gdkfb

[Geert Uytterhoeven <geert@linux-m68k.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4007 bytes --]

On Mon, 23 Aug 2004, Gerd Knorr wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> > Attached is a patch to implement a very preliminary frame buffer device
> > on top of GTK/GDK, as some of you may have seen at OLS.
>
> Mine runs directly on libX11, without any GUI toolkit involved (and

Very nice!

> stealing ENTER keys ;)

That's the advantage. The disadvantage is that's it's more difficult to
write a GUI for it...

My main reason to work on a frame buffer device for UML is debugging the
fbdev subsystem. I.e. I want a GUI to tune various parameters
(resolution, color depth, pixel format, ...).

> >   - Resolution is fixed to 640x480, 256 colors.
>
> Size is configurable at boot time.  Runs on TrueColor displays only.
> Screen parameters are passed through, i.e. if your X11 display is
> 16bpp the fb device inside the uml machine will have 16bpp as well, so
> I don't have to convert any data ;)

That's indeed simple. Have you tried running on X with depth 24?
So far I tried on my Athlon with Radeon 9200 in depth 24, and I get the
attached result (xdpyinfo output attached as well). Colors are a bit
off.

> >   - It uses 2 threads: one for handling widget events, and another one to
> >     update the screen every second.  Calling the update routines from
> >     gdkfb_kern.c when the screen contents are changed using
> >     fillrect/copyarea/imgblt didn't work.
>
> One thread for the communication with the X-Server, any events (fb
> updates, data on the X11 socket) will wake up that thread to handle
> it.  Screen updates can happen much more often than once per second.
> Only changed screen areas will be updated.

You seem to have much more experience with threads in UML than I have...

> >   - Console and penguin logo (special UML logo) works.
>
> Same here (no special logo through).

So I attached a patch to bring it back ;-)

> >   - Userspace access to the frame buffer doesn't work yet.
>
> Same here.  Havn't even looked at that yet.  The memory block for the
> framebuffer is either simply malloced or a shared memory segment,
> depending on whenever sharing memory with the X-Server works or not
> (MIT-SHM Extention).
>
> Q1: Can I map that into the address space of a uml process?

Maybe. It may be safer to use kmalloc() (limited size), or just steal it from
the UML system memory, to make sure /dev/fb mmap() can use a similar
implementation as /dev/mem mmap() (this assumes /dev/mem mmap() works in
UML).

> Q2: Any chance to track the changes (using page faults maybe?),
>     so I can do more clever screen updates than simply blitting
>     the whole screen now and then?

BenH told me at OLS that Mac-On-Linux uses page faults.

> >   - It works (usually ;-) on my Mobile Pentium III laptop (both 2.4.24+SKAS and
> >     2.6.7+SKAS hosts, custom config). I get a window where I can enter
> >     commands. Pressing some keys may make it crash.
>
> I've tested it on one machine only.

Me too! And it works fine (read: stable) on my Athlon!

> >   - The patch includes Gerd Knorr's (a pity I didn't manage to find you at
> >     OLS!) clean up of the console/terminal code, with some modifications:
> >       o I modified the stdio console (which you don't need for gdkfb) not to
> >         panic if it cannot register its console, since it conflicts with the
> > 	normal CONFIG_VT console subsystem.
>
> The updated patch does that as well now.  There seems to be no way to
> switch at runtime between the stdio console and the vt subsystem, if
> vt is enabled it is registered for /dev/tty<n> unconditionally, even
> without any console driver being activated (no dummy console, no
> fbcon).

You can look at the logic of take_over_console().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[-- Attachment #2: Type: IMAGE/PNG, Size: 39897 bytes --]

[-- Attachment #3: Type: TEXT/PLAIN, Size: 4228 bytes --]

name of display:    :1.0
version number:    11.0
vendor string:    The XFree86 Project, Inc
vendor release number:    40300001
XFree86 version: 4.3.0.1
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x142e891, revert to Parent
number of extensions:    30
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RECORD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-DGA
    XFree86-DRI
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1152x900 pixels (293x229 millimeters)
  resolution:    100x100 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x40
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0x5a20bd
    KeyPressMask             ButtonPressMask          ButtonReleaseMask        
    EnterWindowMask          LeaveWindowMask          PointerMotionHintMask    
    ButtonMotionMask         StructureNotifyMask      SubstructureNotifyMask   
    SubstructureRedirectMask PropertyChangeMask       
  number of visuals:    8
  default visual id:  0x23
  visual:
    visual id:    0x23
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x24
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x25
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x26
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x27
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x28
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x29
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2a
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

[-- Attachment #4: Type: APPLICATION/OCTET-STREAM, Size: 11658 bytes --]