[uml-devel] gdkfb

[uml-devel] gdkfb

[Geert Uytterhoeven]

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


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.

  - Resolution is fixed to 640x480, 256 colors.
  - 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.
  - Console and penguin logo (special UML logo) works.
  - Userspace access to the frame buffer doesn't work yet.
  - 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.
  - On my Athlon XP (2.6.7+SKAS host, config based on the Debian
    kernel-image-2.6.7-1-k7 config), it crashed very early until I enlarged the
    stack sizes (STACKSIZE) of the gdkfb threads.  However, even then the
    update thread still hangs somewhere after the initial repaint. Userland
    libraries are exactly the same as on the laptop. Strange...
  - You have to explicitly enable gdkfb on the kernel command line, e.g.

        ./linux ubd0=/home/geert/uml/root_fs init=/bin/bash console=stderr \
	    console=tty0  gdkfb

  - It needs SKAS, since TT creates a statically linked image (libX11 needs
    libpthread when statically linked, and UML crashes when just linked with
    libpthread)
  - 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.
      o I moved the stderr console to a separate file with its own config
        option CONFIG_STDERR_CONSOLE, so you can use it even if
	CONFIG_STDIO_CONSOLE is disabled.
  - The code uses GTK 1.2, but 2.0 works a bit with some modifications to the
    Makefiles (See gtk-config vs. pkg-config). GTK2.0 seems to always consume
    the ENTER key, which prohibits you from entering input.

Enjoy, and happy hacking ;-)

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: APPLICATION/octet-stream, Size: 27877 bytes --]

[uml-devel] Re: gdkfb

[Geert Uytterhoeven]

On Mon, 2 Aug 2004, Geert Uytterhoeven wrote:
>   - On my Athlon XP (2.6.7+SKAS host, config based on the Debian
>     kernel-image-2.6.7-1-k7 config), it crashed very early until I enlarged the
>     stack sizes (STACKSIZE) of the gdkfb threads.  However, even then the
>     update thread still hangs somewhere after the initial repaint. Userland
>     libraries are exactly the same as on the laptop. Strange...

BTW, is there a way to check how much stack a thread really needs? I
tried poisoning the stack with 0xdeadbeef during initializating, but it
looks like clone() will clear it to all zeroes, since afterwards gdb
found zeroes only.

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


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Gerd Knorr]

  Hi,

My framebuffer experiments reached a usable state now as well.  The
patch should show up shortly at:

        http://www.suse.de/~kraxel/uml/patches/

The terminal cleanup patch is updated as well, see comments below.

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
stealing ENTER keys ;)

>   - 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 ;)

>   - 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.

>   - Console and penguin logo (special UML logo) works.

Same here (no special logo through).

>   - 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?
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?

>   - 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.

>         ./linux ubd0=/home/geert/uml/root_fs init=/bin/bash console=stderr \
> 	    console=tty0  gdkfb

linux console=tty0 x11=800x600

>   - It needs SKAS, since TT creates a statically linked image (libX11 needs
>     libpthread when statically linked, and UML crashes when just linked with
>     libpthread)

Same here ;)

>   - 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).

>       o I moved the stderr console to a separate file with its own config
>         option CONFIG_STDERR_CONSOLE, so you can use it even if
> 	CONFIG_STDIO_CONSOLE is disabled.

Updated the terminal patch to do that as well.  I've also swapped
ssl.o and stdio_console.o in the Makefile to fixup the link order,
thus the stdio console is registered first and becomes the default
console as long as the users don't enable the new config options.

If CONFIG_STDERR_CONSOLE is enabled it will allways be the default
console through as it registeres _very_ early.  CONFIG_VT will
conflict with the stdio_console as well (see above).  Note that you
have to enable CONFIG_EMBEDDED if you want to disable CONFIG_VT.

Jeff, is that good enougth for backward compatibility?

Not sure how to handle that best in the long run.  IMHO we should
simply drop the stdio_console.

  Gerd

-- 
return -ENOSIG;


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Digital Infra, Inc.]

You know coLinux? Developing a fb is also underway on coLinux devel ML.
For example, clicking this URL shows you a very rough overview.
http://www.google.co.jp/search?hl=ja&lr=&ie=UTF-8&c2coff=1&q=+site:article.gmane.org+colinux+frame+buffer

                Okajima, Jun. Tokyo, Japan.


>
>  Hi,
>
>My framebuffer experiments reached a usable state now as well.  The
>patch should show up shortly at:
>
>        http://www.suse.de/~kraxel/uml/patches/
>
>The terminal cleanup patch is updated as well, see comments below.
>
>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
>stealing ENTER keys ;)
>
>>   - 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 ;)
>
>>   - 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.
>
>>   - Console and penguin logo (special UML logo) works.
>
>Same here (no special logo through).
>
>>   - 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?
>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?
>
>>   - 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.
>
>>         ./linux ubd0=/home/geert/uml/root_fs init=/bin/bash console=stderr \
>> 	    console=tty0  gdkfb
>
>linux console=tty0 x11=800x600
>
>>   - It needs SKAS, since TT creates a statically linked image (libX11 needs
>>     libpthread when statically linked, and UML crashes when just linked with
>>     libpthread)
>
>Same here ;)
>
>>   - 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).
>
>>       o I moved the stderr console to a separate file with its own config
>>         option CONFIG_STDERR_CONSOLE, so you can use it even if
>> 	CONFIG_STDIO_CONSOLE is disabled.
>
>Updated the terminal patch to do that as well.  I've also swapped
>ssl.o and stdio_console.o in the Makefile to fixup the link order,
>thus the stdio console is registered first and becomes the default
>console as long as the users don't enable the new config options.
>
>If CONFIG_STDERR_CONSOLE is enabled it will allways be the default
>console through as it registeres _very_ early.  CONFIG_VT will
>conflict with the stdio_console as well (see above).  Note that you
>have to enable CONFIG_EMBEDDED if you want to disable CONFIG_VT.
>
>Jeff, is that good enougth for backward compatibility?
>
>Not sure how to handle that best in the long run.  IMHO we should
>simply drop the stdio_console.
>
>  Gerd
>
>-- 
>return -ENOSIG;
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>User-mode-linux-devel mailing list
>User-mode-linux-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Geert Uytterhoeven]

[-- 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 --]

Re: [uml-devel] gdkfb

[Gerd Knorr]

> > stealing ENTER keys ;)
> 
> That's the advantage. The disadvantage is that's it's more difficult to
> write a GUI for it...

I don't plan to write a GUI.

> 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, ...).

Ok, thats a different focus ;)

> > 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.

Yep, here as well.  Looks like the X-Server uses 32 bit/pixel but x11fb
uses 24 bit/pixel.  I had tested 16bpp only.

> > 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...

It's my first uml kernel thread ;)

But I have both general X11 and kernel programming experience, which
helps alot, yes.

> > Same here (no special logo through).
> 
> So I attached a patch to bring it back ;-)

I'll have a look.

> > >   - 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).

Problem is I _want_ use shared memory (if possible) for performance
reasons.  And if possible remap that directly into the applications
address space.  Looking at /dev/mem is a nice idea through ;)

> > 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.

Do you have details on that?

Device drivers can catch missing pages via ->no_page() handler.  Not
sure whenever it is possible to catch write access to read-only mappings
as well, but as apps usually do write-only access to fb memory not
having read-only mappings shouldn't hurt much.

So one possible way I can see is to map in the pages in the nopage
handler.  For screen updates you can check which pages are actually
mapped and only update these.  And also unmap them, so you'll get a new
page fault if the application writes to them again.

> > 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().

No, doesn't help.  The current uml stdio console acts one level below
that.  It doesn't register as linux console driver, but as tty driver
for the major/minor numbers usually used by the linux console subsystem
for the virtual consoles.

  Gerd

-- 
return -ENOSIG;


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Geert Uytterhoeven]

On Tue, 24 Aug 2004, Gerd Knorr wrote:
> > > 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.
>
> Do you have details on that?

No, I haven't looked at MOL yet.

> > You can look at the logic of take_over_console().
>
> No, doesn't help.  The current uml stdio console acts one level below
> that.  It doesn't register as linux console driver, but as tty driver
> for the major/minor numbers usually used by the linux console subsystem
> for the virtual consoles.

Yep, forgot about that.

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Gerd Knorr]

> That's indeed simple. Have you tried running on X with depth 24?

Looks much better now, hope I didn't broke 16 bpp ;)

  Gerd

--- arch/um/drivers/x11_user.c~	2004-08-23 14:56:49.000000000 +0200
+++ arch/um/drivers/x11_user.c	2004-08-24 11:06:44.286858589 +0200
@@ -233,7 +233,7 @@
 	if (0 == n)
 		goto fail_free;
 	win->vi = info[0];
-	bytes_pp = (win->vi.depth+7)/8;
+//	bytes_pp = (win->vi.depth+7)/8;
 	XFree(info);
 	if (win->vi.class != TrueColor && win->vi.class != DirectColor)
 		goto fail_free;
@@ -246,6 +246,7 @@
 				      width, height);
 	if (NULL == win->ximage)
 		goto shm_error;
+	bytes_pp = win->ximage->bitmap_pad/8;
 	win->shminfo.shmid = shmget(IPC_PRIVATE,
 				    win->ximage->bytes_per_line * win->ximage->height,
 				    IPC_CREAT | 0777);


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] gdkfb

[Geert Uytterhoeven]

On Tue, 24 Aug 2004, Gerd Knorr wrote:
> > That's indeed simple. Have you tried running on X with depth 24?
>
> Looks much better now, hope I didn't broke 16 bpp ;)

Thanks, works fine in 24 bpp. Haven't tried anything else, though.

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel