linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] LCD FB + VC

[Fabien L. D. <fa...@ce...>]

I am currently developping a frame buffer drivers for a Samsung LCD. The
LCD is connected to the system trough the USB chain, but fb access works
fine (I can draw ;-p ). The only annoying thing is that when I register my
fb driver it takes over all my VC.

How can I create a new VC (tty?) using my fb driver only?
How can I keep my already existing VC using vgacon ? 

Thanks in advance for your help.

--
------------------------+
Fabien Lebaillif Delamare
R&D Engineer
------------------------+
Office : +65 844 1301
HP : +65 9848 1431
------------------------+
18 Tannery Lane 
#03-05 Lian Tong Building
Singapore 347780
------------------------+

[Linux-fbdev-devel] RE: [linux-fbdev] frame buffer / fixed freq mon question

[Jim H. <jim...@ac...>]

On 17-May-2001 Larry Mulder wrote:
> I have X windows (XFree86-3.3.6) setup with a mach64 based video card to
> drive a fixed frequency Sun monitor OEM's by SONY (GDM-1962B),   However,
> you might well know that when connected to a PC, these fixed frequency
> monitors don't understand standard VGA text mode... I am just curious if it
> would be possible to modify either the atyfb or the vesafb driver in the
> linux kernel to drive this monitor using the fixed freq signals it needs?

I have (nearly) exactly the setup you describe - fixed frequency Sun monitor
driven from a PC. I am using a Permedia card not Mach64, but just because a
Permedia card is what I had. And I am using the frame buffer driver to get a
very loverly console.

I suspect (but don't know for definite) that the vesafb driver won't work, as
I think it uses only VESA sanctioned modes available from the card, and Sun's
resolution isn't one of those.

But I would hope that the atyfb driver would allow you to set your own output
mode, either via boot parameters (if you can with atyfb) or by using fbset on
boot. Here's my fbset settings (given in X style first for comparison with your
X settings):

mail:/home/jim# fbset -s -x

Mode "1152x900"
    # D: 92.945 MHz, H: 61.799 kHz, V: 65.954 Hz
    DotClock 92.946
    HTimings 1152 1184 1312 1504
    VTimings 900 902 906 937
    Flags    "-HSync" "-VSync"
EndMode

mail:/home/jim# fbset -s

mode "1152x900-66"
    # D: 92.945 MHz, H: 61.799 kHz, V: 65.954 Hz
    geometry 1152 900 1152 900 16
    timings 10759 192 32 31 2 128 4
    rgba 5/11,6/5,5/0,0/0
endmode

Set your own mode, and you should get a properly working console.

In the case of the Permedia driver, you can only set a precanned mode from boot
parameters, so I added a 'Sun fixed frequency' mode and rebuilt. (I did once
submit a patch to the driver author to add specifying mode by its components,
but it never made it).

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift.

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[Dawud, M. <muh...@in...>]

Hi all,

I've donwloaded the updated i810 framebuffer drivers. Pardon me for asking
but I'm not exactly a seasoned Linux whiz and I understand that this
question is rather trivial but I've tried a few things so far but they
haven't worked... I don't really know how I can install and enable the
drivers. In the tarred file, there is only two files which are i810fb.c &
i810fb.h. What I've done so far is :-

	- I've put both the i810fb.c and i810fb.h in the
/usr/src/linux/drivers/video directory
	- I've also downloaded a previous version of drivers_video.tgz, and
I've placed the Config.in and the fbmem.c file in the
/usr/src/linux/drivers/video directory.
	- What's next.... any tips....

Thanks,
Dawud



-----Original Message-----
From: Tea Age [mailto:th...@vi...]
Sent: Thursday, May 17, 2001 12:36 AM
To: Geert Uytterhoeven; James Simmons
Cc: Dawud, Muhd; antirez; lin...@li...
Subject: Re: [Linux-fbdev-devel] Query on framebuffer implementations


On Tuesday 15 May 2001 19:40, Geert Uytterhoeven wrote:
> On Tue, 15 May 2001, James Simmons wrote:
> > > Currently I'm using an i810 machine which does not support VESA 2.0,
> >
> > Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
>
>                                                   ^^^^^^
> `should be', like in `should be there, but it isn't yet'.

I have no idea about the fbdev CVS and its policy.
The latest copy I know, can be found here:
http://www.visuelle-maschinen.de/ctfb/i810/i810fb1-06.tgz

Thomas

Re: [Linux-fbdev-devel] restrict text area?

[James S. <jsi...@tr...>]

 
> I want to draw a picture to the fb, and allow texts only below the
> picture, as it is at the bootup process.
> can I do it somehow, or is it hacked into the framebuffer initialization?

You have to open the tty and send a escape sequence to set what are the
top and bottom rows. I believe it is \33[1;30r you have to write to the
tty. The 1 represents the top row and the 30 represents the bottom row.
Since this is by row you figure out how many rows the image takes you. You
do this by taking the image size and divide by the font height then round
it up if you have a remander. This is what you have to pass for your top
row variable. Remember to reset it after exit the program :-)

[Linux-fbdev-devel] restrict text area?

[BERECZ S. <sz...@in...>]

Hi!

I want to draw a picture to the fb, and allow texts only below the
picture, as it is at the bootup process.
can I do it somehow, or is it hacked into the framebuffer initialization?

Bye,
Szabi

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[Geert U. <ge...@li...>]

On Wed, 16 May 2001, James Simmons wrote:
> > On Tue, 15 May 2001, James Simmons wrote:
> > > BTW. Have you seen the thread on the kernel mailing list?
> > 
> > Which thread?
> 
> Re: LANANA: To Pending Device Number Registrants

Yes, cfr. my postings yesterday and today :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Query on framebuffer implementations

[Tea A. <th...@vi...>]

On Tuesday 15 May 2001 19:40, Geert Uytterhoeven wrote:
> On Tue, 15 May 2001, James Simmons wrote:
> > > Currently I'm using an i810 machine which does not support VESA 2.0,
> >
> > Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
>
>                                                   ^^^^^^
> `should be', like in `should be there, but it isn't yet'.

I have no idea about the fbdev CVS and its policy.
The latest copy I know, can be found here:
http://www.visuelle-maschinen.de/ctfb/i810/i810fb1-06.tgz

Thomas

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[James S. <jsi...@tr...>]

> On Tue, 15 May 2001, James Simmons wrote:
> > BTW. Have you seen the thread on the kernel mailing list?
> 
> Which thread?

Re: LANANA: To Pending Device Number Registrants


I have talked to Viro and we are going to cook up a fbdev filesystem over
the next few days.

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[Geert U. <ge...@li...>]

On Tue, 15 May 2001, James Simmons wrote:
> BTW. Have you seen the thread on the kernel mailing list?

Which thread?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[James S. <jsi...@tr...>]

> > Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
>                                                   ^^^^^^
> `should be', like in `should be there, but it isn't yet'.
> 
> BTW, I'm about to check in the new atyfb.

Okay. 

BTW. Have you seen the thread on the kernel mailing list?

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[Geert U. <ge...@li...>]

On Tue, 15 May 2001, James Simmons wrote:
> > Currently I'm using an i810 machine which does not support VESA 2.0, 
> 
> Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
                                                  ^^^^^^
`should be', like in `should be there, but it isn't yet'.

BTW, I'm about to check in the new atyfb.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[James S. <jsi...@tr...>]

> Currently I'm using an i810 machine which does not support VESA 2.0, 

Their is a i810 framebuffer driver avaiable. It should be in fbdev CVS.
You need andrew morton's console patch and also arange the agp code to
initialize before fbmem_init.

RE: [Linux-fbdev-devel] Query on framebuffer implementations

[Dawud, M. <muh...@in...>]

Hi Salvatore,

Currently I'm using an i810 machine which does not support VESA 2.0, thus my
need to use VGA16 framebuffer support in the kernel which is a bummer
because the resolution is only so much. I've downloaded the vga256fb,
however after a successful compilation I can't seem to execute the file....

	When executing vga256ctrl, it cannot find the available modes and
displays the following error :

		Available modes:
		ioctl: Invalid argument
		---
		ioctl(VGA256_GET_FLAGS): Invalid argument
		ioctl(VGA256_GET_LE_FRAMERATE): Invalid argument
		Linear emulation frame rate: 0
		smart update: off
		update by line: off
		ignore nonstd: off

I'd like to design a framebuffer based graphic GUI during the boot up phase
that covers all the messages after the kernel messages. The graphic should
cover all the INIT executables. In the second stage I'd like to take the
previously designed GUI and replace it with a GUI that can select which
services that you'd prefer before the INIT begins. I was looking into the
methods to implement this, however there seems to be a lack of resources on
this... I believe my best bet is a framebuffer implementation...

The only way to implement this I think would be to include my existing
framebuffer dump (just a few horizontal lines streaking across the screen)
and patch it into the kernel. I don't however know where to include it in
the kernel and I don't really know where to modify ... I'm still new to
kernel hacking...... Still reading up.....

The closest that I can come up to is the Linux Progressive Patch, which
patches over the kernel boot up with a Win98' like logo for the Linux
machine that you are using. Unfortunately the patch is only for VESA 2.0
compliant machines... My meager 166 Pentium PC with an S3 card can be
considered exempt from the requirements above....

Any pointers or help would be very much appreciated..... Thanks again
guys.....

Regards,
Dawud


-----Original Message-----
From: antirez [mailto:an...@in...]
Sent: Monday, May 14, 2001 7:43 PM
To: Dawud, Muhd
Cc: lin...@li...
Subject: Re: [Linux-fbdev-devel] Query on framebuffer implementations


On Mon, May 14, 2001 at 12:36:24AM +0800, Dawud, Muhd wrote:
> Hi all,
> 
> I'd like to ask a quick question on framebuffer implementations if you
guys
> don't mind...... 
> 
> In recent releases of the red-hat linux (I'm using 7.0) the bootloader is
a
> graphical interface, I'm wondering how I could program something like
this.
> My current machine is a 166MHZ Pentium with only VESA 1.2 support so the
> best framebuffer support that I have is VGA16. Furthermore I can only come
> up with ugly looking graphics in 16 colors which can only start after I've
> logged into the system. The lilo GUI is excellent compared to my lousy
GUI,

You can use the patch at http://www.kyuzz.org/antirez/vga256fb.html
to get 360x480 in 256 colors without VESA 2.0 support.
It seems there are different patches to add this support in the
linux framebuffer, but I don't know where to get they.

> does anyone know how lilo does this... I presume that it is also a
> framebuffer dump but how does it get 256K resolution. I would really like
to
> write some kind of personalized GUI to replace the red-hat lilo prompt but
I
> am at a loss on how to proceed... Can anyone out there kindly offer me
some
> pointers ???

I don't know how this works. Maybe all the graphic support is implemented
in the boot loader itself. I can't see how a boot loader can directly
use the linux framebuffer abstraction: the boot loader itself contains
portion of the linux kernel? Is it a "linux booting linux" hack?

> So in essence my problem is two-fold, I don't know how to load my
customized
> GUI to replace lilo's gui and I don't know how to code a nicer GUI using
> framebuffers. Again I don't know if I'm attacking the problem in a wrong
> way. Any help would be very much appreciated.

You should provide more information about this boot loader.

regards,
Salvatore

-- 
Salvatore Sanfilippo <an...@in...>
http://www.kyuzz.org/antirez
finger an...@te... for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Re: [Linux-fbdev-devel] Query on framebuffer implementation

[Petr V. <VAN...@vc...>]

On 14 May 01 at 20:07, James Simmons wrote:
> > Maybe all the graphic support is implemented in the boot loader itself.
> 
> Correct. I haven't looked at lilo's code but I have seen a few bootloaders
> for embedded devices. They all implement the graphics chip itself. For
> lilo you supply a line vga=some_mode_number. Since lilo runs in real mode

At least Debian's LILO uses normal 640x480 16colors (mode 0x12).
                                                    Petr
                                                    

Re: [Linux-fbdev-devel] vga256fb

[antirez <an...@in...>]

On Tue, May 15, 2001 at 08:10:54AM +0200, Geert Uytterhoeven wrote:
> On Mon, 14 May 2001, James Simmons wrote:
> > > The other problem is that without a PACKED_PIXEL display all the
> > > userspace currently available will not work.
> > 
> > Their is not much you can do to get around this besides writing a native
> > framebuffer :-). A emulation mode is way to slow. In theory you could this
> > for atari and ilbm modes but it would go so sloooow.
> 
> I've been thinking about this. I see 2 possible approaches for emulation:
> 
>   - Map the fake frame buffer read-only. Trap all write accesses and convert
>     between packed pixels and native format in the trap handler. Expensive due
>     to many context switches.
> 
>   - Map the fake frame buffer read-only. In the trap handler, make the page
>     writable and rerun the write. In a timer handler, convert all pages that
>     are writable and make them read-only again. Faster, but more visible delay
>     (however, if the timer handler runs sufficiently frequent you won't
>     notice).

This is interesting IMHO. I tried to do something like this (i.e. to
convert only the pages modified) using the dirty flag in the physical
page, but experimenting problems:

Instead to update all the video memory in the timer handler, vga256fb
try to run all the pages checking for the dirty bit, if at least
one page is dirty update the entire video memory. Then flush the TLB.

As you can guess it's brain-dead since it can update just the page
that changed, and it flushes all the entry from the TLB,
but I stopped here because it works only for the
graphic console, and not when I mmap the framebuffer from userspace.
(you can see the code in the current vga256fb implementation but it's
 disabled by default by #ifdef, the feature is called SMARTUPDATE).

I investigated a bit, and the problem seems that the dirty flag
isn't unique: Both the no_page method or remap_page_range create
a new page entry with a _different_ pte. Maybe with some hack I
can create different pages entry with the pmd that points to the
same pte, but this is broken anyway since not only the dirty
flag will be unique, but also all the other flags :(

But I guess that with the method you shown it can work, something like:

- Map the fake frame buffer read-only. In the trap handler, make the
  page writable and set a bit in a bitmap. In the timer handler copy
  all the pages with the associated bit in the bitmap set to the
  real VGA memory (converting it from linear to planar of course), and
  remake the modified pages read-only.

This is just what vga256fb do, but with the "update-only-the-modified-page"
trick, that will save a lot of CPU all the times the only thing
modified in the screen is the cursor, or the pointer, or nothing.
The problem with this is that for a simple one-line scroll all the
pages will be updated, and the trap called xres*yres/PAGE_SIZE times,
so you optimized for all the times the console is idle, but it will
be probably shower than the current vga256fb implementation for animations and
so on.

I'll try!

cheers,
Salvatore

-- 
Salvatore Sanfilippo <an...@in...>
http://www.kyuzz.org/antirez
finger an...@te... for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Re: [Linux-fbdev-devel] vga256fb

[Geert U. <ge...@li...>]

On Mon, 14 May 2001, James Simmons wrote:
> > The other problem is that without a PACKED_PIXEL display all the
> > userspace currently available will not work.
> 
> Their is not much you can do to get around this besides writing a native
> framebuffer :-). A emulation mode is way to slow. In theory you could this
> for atari and ilbm modes but it would go so sloooow.

I've been thinking about this. I see 2 possible approaches for emulation:

  - Map the fake frame buffer read-only. Trap all write accesses and convert
    between packed pixels and native format in the trap handler. Expensive due
    to many context switches.

  - Map the fake frame buffer read-only. In the trap handler, make the page
    writable and rerun the write. In a timer handler, convert all pages that
    are writable and make them read-only again. Faster, but more visible delay
    (however, if the timer handler runs sufficiently frequent you won't
    notice).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] fbtest

[Geert U. <ge...@li...>]

On Mon, 14 May 2001, Scott A McConnell wrote:
> Thanks for making these available.

Note that not everything is working well yet.

> What is -lnetpbm?

The library part of netpbm. Debian has one libnetpbm.{a,so}.

> I grabed netpbm-9.14
> 
> I ended up having to change the main Makefile to:
> 
> LIBS += -lpbm -lpgm -lppm

I noticed this under Solaris as well: instead of libnetpbm, you may have
separate libp[bgm].{a,so}.

> I was wondering about how we might use these tests on embedded systems
> like ARM or MIPS. Has NETPBM been cross compiled?

If it runs Debian, it has netpbm :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Rivafb maintainer, 2.4.4-ac7 oops

[James S. <jsi...@tr...>]

Thank you the info. I'm going threw the code to find teh problem. Please
be patient. Thank you.

Re: [Linux-fbdev-devel] vga256fb

[James S. <jsi...@tr...>]

> I tried something like this but I was unable to keep the page
> fault: where I can flush the page tables? memory.c will create
> a page entry with the physical address I returned by the no_page
> handler, so I should flush the page in mm/memory.c?

Defintely not in memory.c. It should be done in the driver. I can't
remember of teh top of my head how it was done. I have to go look at some
old code to handle this.
 
> The other problem is that without a PACKED_PIXEL display all the
> userspace currently available will not work.

Their is not much you can do to get around this besides writing a native
framebuffer :-). A emulation mode is way to slow. In theory you could this
for atari and ilbm modes but it would go so sloooow.

> Also as you noted you need to flush the page table, and it seems
> it can't be done in a module ;(

I seriously doubt it would be a problem. It might not be exported to
modules but that is easily fixed. You also only want to flush the page
tables only when you need to. Like when you leave one bank and go to
another.

Re: [Linux-fbdev-devel] Query on framebuffer implementations

[James S. <jsi...@tr...>]

> Maybe all the graphic support is implemented in the boot loader itself.

Correct. I haven't looked at lilo's code but I have seen a few bootloaders
for embedded devices. They all implement the graphics chip itself. For
lilo you supply a line vga=some_mode_number. Since lilo runs in real mode
it most likely calls the BIOS to set the video mode. It uses this value to
see if it should use VESA extended BIOS calls or classic vga BIOS calls to
set the video mode. Try asking for a vga text mode when running vesafb or
vice versa and you will never see your display. For the ix86 platform this
info is extracted from the BIOS and passed to the kernel after it enters
protect mode.

[Linux-fbdev-devel] ATI Rage 128 Pro Fury (TV/out) framebuffer question

[Thomas V. S. <th...@ur...>]

Hi,

I have the above mentioned card (at least that's what X-probing tells me)
and I succesfully got vesa framebuffer working.  If I use the 640x480 or
800x600 in 16 bit mode, I can see my X both on a computer screen and on
the TV screen, connected at the same time.

I tried getting the aty128fb device to work instead of the vesa
framebuffer device, but this fails : my TV screen goes blue (indicating no
signal) and I get nothing on my computer monitor.  I tried the same modes,
as well as others.

My questions are :

1) I removed Vesa FB from the kernel for this, is that the right thing to
do ?

2) I have gathered from some newsgroup postings that the rage 128 fury pro
is different from both the rage 128 fury (regular) and the rage fury pro;
does this mean the aty128fb driver might not even work ?

3) Is there any other way than through framebuffer devices (which seems to
slow down X a lot more than when run with the native driver) to get tv-out
working ?

please reply to th...@ap...
thanks in advance

thomas

<-*-                      -*->
if you ever lay a finger on my left side
if you ever lay a finger on me I will open
<-*- th...@ap... -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/

Re: [Linux-fbdev-devel] fbtest

[Scott A M. <sam...@co...>]

Geert Uytterhoeven wrote:


Geert,

Thanks for making these available.

What is -lnetpbm?


I grabed netpbm-9.14

I ended up having to change the main Makefile to:

LIBS += -lpbm -lpgm -lppm



I was wondering about how we might use these tests on embedded systems
like ARM or MIPS. Has NETPBM been cross compiled?

Scott

[Linux-fbdev-devel] Datasheet for GD-5434

[Wayne G. <wgo...@ya...>]

Dear All,

I'm trying to make a Cirrus Logic GD-5434 chip work
with a mips board. I tried to get the datasheet for
the device but it is no longer on the Cirrus Logic
site. And the site they refer you to ISDcorp.com,
seems permanently down.

Would anyone on this list happen to have it in PDF
form ?

If you do could you send it to me ?

TIA

Wayne

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: [Linux-fbdev-devel] vga256fb

[James S. <jsi...@tr...>]

> > Yuck! You can use the no-page trick to handle banked video cards. Its been
> > done before. Noramlly VGA uses A000 to AFFFF. Once you go beyond that
> > (B000) you can stop this is in a page fault handler and then program the
> > register to switch to a new bank. Note you have to keep a eye on what the
> > current bank is at all times (think SMP). You also have to flush the page
> > tables so you can keep page faulting :-(
> 
> I tried something like this but I was unable to keep the page
> fault: where I can flush the page tables? memory.c will create
> a page entry with the physical address I returned by the no_page
> handler, so I should flush the page in mm/memory.c?

It can be done from a module or inside the kernel and it is platform
independent. See linux/Documentation/cachetlb.txt. Note it is a expensive
operation. I would only flush the TLB when you need to switch to another
bank.

> The other problem is that without a PACKED_PIXEL display all the
> userspace currently available will not work.
> To make it working without too problems with old PCs was my goal.

Well if the video mmeory is not layed out in packed pixel mode their isn't
much you can do. You have to let userland know that the mode is not packed
pixels but something else. Then the userland program has to deal with it. 

Re: [Linux-fbdev-devel] vga256fb

[antirez <an...@in...>]

On Mon, May 14, 2001 at 09:50:15AM -0700, James Simmons wrote:
> 
> > No I can't use the no-page trick to remap the videoram pages and change
> > the hardware state, unfortunatelly: it seems not possible.
> > I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There
> > is a different kernel timer that updates the video memory and
> > switches the registers to write to the proper video plane.
> 
> Yuck! You can use the no-page trick to handle banked video cards. Its been
> done before. Noramlly VGA uses A000 to AFFFF. Once you go beyond that
> (B000) you can stop this is in a page fault handler and then program the
> register to switch to a new bank. Note you have to keep a eye on what the
> current bank is at all times (think SMP). You also have to flush the page
> tables so you can keep page faulting :-(

I tried something like this but I was unable to keep the page
fault: where I can flush the page tables? memory.c will create
a page entry with the physical address I returned by the no_page
handler, so I should flush the page in mm/memory.c?

The other problem is that without a PACKED_PIXEL display all the
userspace currently available will not work.
To make it working without too problems with old PCs was my goal.

Also as you noted you need to flush the page table, and it seems
it can't be done in a module ;(

BTW the trick is very interesting! I'll try to implement it as
'nonstd == 2' or something like this if I understand how to
keep the page faulting.

thanks!
Salvatore

-- 
Salvatore Sanfilippo <an...@in...>
http://www.kyuzz.org/antirez
finger an...@te... for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF