fbdv/fbcon pending problems

Hi !

Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

 - First one, I will deal with, just writing it for completeness: When
switching from KD_GRAPHICS to KD_TEXT (either same console changing mode
or switching to a different console), we need a callback so the fbdev
has a chance to restore the accel engine setting (or even the whole
mode, to be safe).

 - Memory corruption problems. There is still at least one identified
when using stty. Just use crazy values, like flipping rows & cols (like
stty rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.

 - mach64 lockups on LT-G (I'll try on an LT-Pro soon) plus other
mach64 bugs in the new version in the bk fbdev, I'll have a patch for
some of the problems, but I didn't find a good explanation for the
accel lockups yet

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

 - Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.

 - On x86, various junk displayed when the fbdev takes over. Reported
by radeonfb users, I couldn't test myself, I don't have an x86 with
radeon at hand for the moment. Apparently, the takeover from vgacon
doesn't properly "convert" the previous VGA text buffer content

 - stty & mode picking. Currently, fbcon_resize() (called when stty is
used to resize the console) will hack a "var" strcture by just putting
new width/height in it and pass that to set_var. The way the various
drivers react to that mostly broken "var" structure is rather random.
We need to explicitely differenciate between a mode that is "complete"
(like what fbset or X passes down the fbdev) or a mode that is just
width/height and eventually a hint of frequency, like what fbcon passes
in this case. I added FB_ACTIVATE_FIND for that purpose, but that needs
better driver support to "pick" up a proper mode. The algorithm for
that isn't trivial. Could be moved to common code.

 - fbset doesn't resize the console. I consider that a regression from
2.4. I have some code based on the notification mecanism to address
that, but it tends to trigger the same memory corruption problem as
reported with stty & bogus coordinates. There is something hairy going
on with console resizes. That code is a bit foreign to me though.

Ok, that's all that comes to my mind right now, help is welcome :)

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Benjamin Herrenschmidt wrote:

Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

...

Ok, that's all that comes to my mind right now, help is welcome :)

IMHO it is rather discouraging that:

FRAMEBUFFER LAYER
P:      James Simmons, Geert Uytterhoeven       
M:      jsimmons@infradead.org, geert@linux-m68k.org    
L:      linux-fbdev-devel@lists.sourceforge.net 
W:      http://www.linux-fbdev.org

$ host www.linux-fbdev.org
Nameserver not responding
www.linux-fbdev.org A record not found, try again


http://linux-fbdev.sourceforge.net/ has no halfway up-to-date information about
the state of 2.6 fbdev devlopment. Sure, one can dig through the mailing list
archives, but if a project is looking for developers I would at least expect a
link to
- the current fbdev source tree
- a TODO that lets me see what work is currently been done by others,
  and what work could be contributed by me

(This is just a suggestion, I don't have time to work on fbdev myself.)

Johannes

Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

A bit. I managed to create the first crack at the ioremap problem with 
machines with lots of memory. Had some problems tho.
 

 - First one, I will deal with, just writing it for completeness: When
switching from KD_GRAPHICS to KD_TEXT (either same console changing mode
or switching to a different console), we need a callback so the fbdev
has a chance to restore the accel engine setting (or even the whole
mode, to be safe).

This is a big problem. It's been around since the beginning of time. Also 
we have the case of fbdev/vgacon systems. Alot fo work has to be done 
here.

 - Memory corruption problems. There is still at least one identified
when using stty. Just use crazy values, like flipping rows & cols (like
stty rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.

Ug. I have to hunt down this problem.

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

Also been around for ever. I think that will be a much easier fix.

 - Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.

strange. I don't have that problem on my systems.

 - On x86, various junk displayed when the fbdev takes over. Reported
by radeonfb users, I couldn't test myself, I don't have an x86 with
radeon at hand for the moment. Apparently, the takeover from vgacon
doesn't properly "convert" the previous VGA text buffer content

I have to try that one out. I know I haven't seen the problem if you
have a fbdev driver and fbcon modular and load them. 
 

 - stty & mode picking. Currently, fbcon_resize() (called when stty is
used to resize the console) will hack a "var" strcture by just putting
new width/height in it and pass that to set_var. The way the various
drivers react to that mostly broken "var" structure is rather random.
We need to explicitely differenciate between a mode that is "complete"
(like what fbset or X passes down the fbdev) or a mode that is just
width/height and eventually a hint of frequency, like what fbcon passes
in this case. I added FB_ACTIVATE_FIND for that purpose, but that needs
better driver support to "pick" up a proper mode. The algorithm for
that isn't trivial. Could be moved to common code.

I think we should do better validating of the var passed in. This also 
needs a bit of work. 

 - fbset doesn't resize the console. I consider that a regression from
2.4. I have some code based on the notification mecanism to address
that, but it tends to trigger the same memory corruption problem as
reported with stty & bogus coordinates. There is something hairy going
on with console resizes. That code is a bit foreign to me though.

I had problems as well. I will have to work on it. 

Other problems have to deal with multiheaded system. Fbcon is multihead 
safe. Alot of gloabl variables that are shared with different framebuffers.
Also the mapping at boot time is really broke. That laso has had problems 
for ages :-( 

On Tue, 2004-02-24 at 05:59, James Simmons wrote:

quoted

Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

A bit. I managed to create the first crack at the ioremap problem with 
machines with lots of memory. Had some problems tho.

I worked around this one in radeonfb by only mapping part of the
framebuffer (see current version in linus tree), but that's sub
optimal. Better is to implement full accel and not map the fb
at all. But good enough for now, the other problems are more
important imho.

This is a big problem. It's been around since the beginning of time. Also 
we have the case of fbdev/vgacon systems. Alot fo work has to be done 
here.

Yes. Working on it.

quoted

 - Memory corruption problems. There is still at least one identified
when using stty. Just use crazy values, like flipping rows & cols (like
stty rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.

Ug. I have to hunt down this problem.

I would appreciate if you did so ;) Please let me know what you find.

quoted

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

Also been around for ever. I think that will be a much easier fix.

Ok.

quoted

 - Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.

strange. I don't have that problem on my systems.

I have this problem since the very beginning. The very first
shift-pageup to display things properly from the back buffer, but to not
_erase_ properly, until you do a bit of ping pong (down up down up) so
that your screen end up properly refreshed.

quoted

 - On x86, various junk displayed when the fbdev takes over. Reported
by radeonfb users, I couldn't test myself, I don't have an x86 with
radeon at hand for the moment. Apparently, the takeover from vgacon
doesn't properly "convert" the previous VGA text buffer content

I have to try that one out. I know I haven't seen the problem if you
have a fbdev driver and fbcon modular and load them. 

I never use modules for fbdevs
 

I think we should do better validating of the var passed in. This also 
needs a bit of work. 

It does. Radeonfb did one step in this direction, but that's not
enough. _BUT_ we still need to differenciate between a full mode 
passed from userland from a mode where we _KNOW_ everything is
bogus but width/height... In the later case, we really want to
find a mode that is just large enough for the passed in width/height
(but not smaller, or just fail if not found) and with the same
hfreq if possible as the current mode. That's really a different
request than a full blown mode coming from userland (like a 'tuning'
tool or whatever...)

The FB_ACTIVATE_FIND is just that. It justs tells the driver to
pick up a mode based on width/height only. We know the rest of
the var is bogus.

I had problems as well. I will have to work on it. 

Other problems have to deal with multiheaded system. Fbcon is multihead 
safe. Alot of gloabl variables that are shared with different framebuffers.
Also the mapping at boot time is really broke. That laso has had problems 
for ages :-( 

Yes, but that's less urgent than the other ones. We really need to fix
those basic behaviour problems before multihead. Multihead will come
later as I will implement dual head support in radeonfb. That leads to
a while bunch of problems with the userland API that need to be improed
too, and that leads to the problem of properly soft booting additional
cards. I have various ideas to address those problems, but that's
definitely less urgent than the list I wrote down.

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

I would appreciate if you did so ;) Please let me know what you find.

Okay. 

I have this problem since the very beginning. The very first
shift-pageup to display things properly from the back buffer, but to not
_erase_ properly, until you do a bit of ping pong (down up down up) so
that your screen end up properly refreshed.

:-( 
 

I never use modules for fbdevs

Its a handy way to track down bugs :-)

It does. Radeonfb did one step in this direction, but that's not
enough. _BUT_ we still need to differenciate between a full mode 
passed from userland from a mode where we _KNOW_ everything is
bogus but width/height... In the later case, we really want to
find a mode that is just large enough for the passed in width/height
(but not smaller, or just fail if not found) and with the same
hfreq if possible as the current mode. That's really a different
request than a full blown mode coming from userland (like a 'tuning'
tool or whatever...)

The FB_ACTIVATE_FIND is just that. It justs tells the driver to
pick up a mode based on width/height only. We know the rest of
the var is bogus.

Its still possible that the user sends in bogus data using 
FB_ACTIVATE_FIND. 
 

Yes, but that's less urgent than the other ones. 

I agree.

We really need to fix
those basic behaviour problems before multihead. Multihead will come
later as I will implement dual head support in radeonfb. That leads to
a while bunch of problems with the userland API that need to be improed
too, 

That is what sysfs is for :-) 

and that leads to the problem of properly soft booting additional
cards. I have various ideas to address those problems, but that's
definitely less urgent than the list I wrote down.

We will talk about this later.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Tue, 24 Feb 2004, Benjamin Herrenschmidt wrote:

On Tue, 2004-02-24 at 05:59, James Simmons wrote:

quoted

I think we should do better validating of the var passed in. This also
needs a bit of work.

It does. Radeonfb did one step in this direction, but that's not
enough. _BUT_ we still need to differenciate between a full mode
passed from userland from a mode where we _KNOW_ everything is
bogus but width/height... In the later case, we really want to
find a mode that is just large enough for the passed in width/height
(but not smaller, or just fail if not found) and with the same
hfreq if possible as the current mode. That's really a different
request than a full blown mode coming from userland (like a 'tuning'
tool or whatever...)

The FB_ACTIVATE_FIND is just that. It justs tells the driver to
pick up a mode based on width/height only. We know the rest of
the var is bogus.

What about renaming it to FB_ACTIVE_RESIZE?

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 is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

What about renaming it to FB_ACTIVE_RESIZE?

Because it's not actually setting any mode, just returns a
valid "var" :) For now, fbcon will just do a set_var
FB_ACTIVATE_NOW right away, but userland may want to use
that to build mode lists without actually changing the mode...

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Mon, Feb 23, 2004 at 11:53:14AM +1100, Benjamin Herrenschmidt wrote:

Hi !

Here's a list of pending issues with fbdev (either upstream or in the
fbdev bk treee), I figured posting it here may help getting more people
on those issues as my time is sparse and I suppose James too.

 - First one, I will deal with, just writing it for completeness: When
switching from KD_GRAPHICS to KD_TEXT (either same console changing mode
or switching to a different console), we need a callback so the fbdev
has a chance to restore the accel engine setting (or even the whole
mode, to be safe).

 - Memory corruption problems. There is still at least one identified
when using stty. Just use crazy values, like flipping rows & cols (like
stty rows 132 cols 30) and usually, you'll see the box blow up very soon
with heavy memory corruption.

 - mach64 lockups on LT-G (I'll try on an LT-Pro soon) plus other
mach64 bugs in the new version in the bk fbdev, I'll have a patch for
some of the problems, but I didn't find a good explanation for the
accel lockups yet

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

 - Back buffer problem: maybe related to the logo ? After boot, doing
shift-pageup to go back to the boot message, usually you get crap
displayed at various places.

 - On x86, various junk displayed when the fbdev takes over. Reported
by radeonfb users, I couldn't test myself, I don't have an x86 with
radeon at hand for the moment. Apparently, the takeover from vgacon
doesn't properly "convert" the previous VGA text buffer content

 - stty & mode picking. Currently, fbcon_resize() (called when stty is
used to resize the console) will hack a "var" strcture by just putting
new width/height in it and pass that to set_var. The way the various
drivers react to that mostly broken "var" structure is rather random.
We need to explicitely differenciate between a mode that is "complete"
(like what fbset or X passes down the fbdev) or a mode that is just
width/height and eventually a hint of frequency, like what fbcon passes
in this case. I added FB_ACTIVATE_FIND for that purpose, but that needs
better driver support to "pick" up a proper mode. The algorithm for
that isn't trivial. Could be moved to common code.

 - fbset doesn't resize the console. I consider that a regression from
2.4. I have some code based on the notification mecanism to address
that, but it tends to trigger the same memory corruption problem as
reported with stty & bogus coordinates. There is something hairy going
on with console resizes. That code is a bit foreign to me though.

Ok, that's all that comes to my mind right now, help is welcome :)

- bus_id for each fbdev, so from userland became posible to identify
  to which card we are controlling.  I know it should be exported via
  sysfs but an ioctl should be really handy as when you program for
  fbdev anyway you have to use ioctl's, just to get the bus_is will
  be a pain use sysfs.

-otto
  


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Mon, 23 Feb 2004, Otto Solares wrote:

On Mon, Feb 23, 2004 at 11:53:14AM +1100, Benjamin Herrenschmidt wrote:
- bus_id for each fbdev, so from userland became posible to identify
  to which card we are controlling.  I know it should be exported via
  sysfs but an ioctl should be really handy as when you program for
  fbdev anyway you have to use ioctl's, just to get the bus_is will
  be a pain use sysfs.

But the goal is to replace these ioctl()s by sysfs, too, isn't it?

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 is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

But the goal is to replace these ioctl()s by sysfs, too, isn't it?

Yes. ioctl should DIE!!!!

On Tue, Feb 24, 2004 at 09:35:35AM +0100, Geert Uytterhoeven wrote:

On Mon, 23 Feb 2004, Otto Solares wrote:

quoted

On Mon, Feb 23, 2004 at 11:53:14AM +1100, Benjamin Herrenschmidt wrote:
- bus_id for each fbdev, so from userland became posible to identify
  to which card we are controlling.  I know it should be exported via
  sysfs but an ioctl should be really handy as when you program for
  fbdev anyway you have to use ioctl's, just to get the bus_is will
  be a pain use sysfs.

But the goal is to replace these ioctl()s by sysfs, too, isn't it?

Sure, hopefully fbdev drivers became more 'intelligent', with just a

echo "1024x768x16-75" > /sys/class/fbdev/0/geometry

they will compute internally the timings or get it from EDID and
glad the user with something correct for the hardware.

cat /sys/class/fbdev/0/modes

will give you the modes supported by the card.

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

By 'fixing the layer' i mean some simple things that could make fbdev
a real graphics solution for linux in the long term:

- fbdev_core (will handle the fbdev/sysfs registration, shared by all
              drivers, most important is the modes handling interface).
- fbdev_xxx  (driver for specific hw, it will only export the interesting
              bits like vmem, ioregs, will handle mmap stuff and ioctl's,
              video modes, no accel of any kind).
- fbdev_xxx_accel (acceleration hooks if any for xxx driver, optional module)
- fbdev_con  (handle console -- already modular in 2.6, will use accel hooks
              if not NULL, optional).
- fbdev_xxx_drm (will handle the DRM for xxx using hooks from fbdev, so we
              could have just a single entity inside the kernel handling a
              specific device, and not the current mess within fbdev and
              drm, optional).

We have now with 2.6 a good input and sound layers.  Just by fixing
the graphics layer many interesting userland projects could be born.

-otto

Sure, hopefully fbdev drivers became more 'intelligent', with just a

echo "1024x768x16-75" > /sys/class/fbdev/0/geometry

they will compute internally the timings or get it from EDID and
glad the user with something correct for the hardware.

cat /sys/class/fbdev/0/modes

will give you the modes supported by the card.

Yes.
 

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be 
used for read and writes on /dev/fbX. Also it is used for software 
cursors. 

By 'fixing the layer' i mean some simple things that could make fbdev
a real graphics solution for linux in the long term:

- fbdev_core (will handle the fbdev/sysfs registration, shared by all
              drivers, most important is the modes handling interface).

Pretty much done.

- fbdev_xxx  (driver for specific hw, it will only export the interesting
              bits like vmem, ioregs, will handle mmap stuff and ioctl's,
              video modes, no accel of any kind).

Have it.

- fbdev_xxx_accel (acceleration hooks if any for xxx driver, optional module)

We need it for the above reasons.

- fbdev_con  (handle console -- already modular in 2.6, will use accel hooks
              if not NULL, optional).

We always need the accel hooks. Some how we have to draw the fonts.

- fbdev_xxx_drm (will handle the DRM for xxx using hooks from fbdev, so we
              could have just a single entity inside the kernel handling a
              specific device, and not the current mess within fbdev and
              drm, optional).

That will be the future.

We have now with 2.6 a good input and sound layers.  Just by fixing
the graphics layer many interesting userland projects could be born.

I agree. The graphics layer is the last frontier.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

quoted

We have now with 2.6 a good input and sound layers.  Just by fixing
the graphics layer many interesting userland projects could be born.

I agree. The graphics layer is the last frontier.

It is. What we really need right now is a proper way to get the mode
lists. but more than that. We need to expose per-output detection data,
mapping of CRTCs to outputs, and a way to change that mapping & trigger
a re-probe. All of that can probably not be done in a completely card
neutral way.  

I've started working on a userland library taking care of managing
the "environment", that is the various screens & heads, their modes,
the geometry (relative screen positions), and such. I haven't gone
very far yet, but the idea is ultimately to have the entire mode
setting go through this library. That include proper interface to
the kernel drivers (whatever they become, fbdev is what we have to
day but that may change) and that also probably means moving some
of the monitor management down to userland.

This library will also be responsible to broadcast, possibly via
D-BUS, events like screen hotplug and mode changes. We are thinking
about interfacing the fd.o xserver on this among others. It will
not do anything about rendering though.

That leads to another issue which is arbitration at the low level
driver between rendering & mode switching. That should be done by
the kernel driver at some point, we need to merge the mode setting
driver (fbdev) and the command queue diver (DRI). Probably moving 
some of the higher level mode management out of the kernel driver
down to this userland library.

Anyway, it's all mostly ideas at this point. I'm trying to get an
API out with a test implementation on top of fbdev. At which point
we'll be able to move further.

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

It is. What we really need right now is a proper way to get the mode
lists. but more than that. We need to expose per-output detection data,
mapping of CRTCs to outputs, and a way to change that mapping & trigger
a re-probe. All of that can probably not be done in a completely card
neutral way.  

Agree.
 

I've started working on a userland library taking care of managing
the "environment", that is the various screens & heads, their modes,
the geometry (relative screen positions), and such. I haven't gone
very far yet, but the idea is ultimately to have the entire mode
setting go through this library. 

   I think this is a bad idea. This has been tried before. In the 
opensource community there is no such a thing as a standard library. 
We can see that with directfb and X windows, sdl, gtk/qt embedded, etc. 
Understand that I have no problem with having lots of libraries. Its 
just the reality is your library will be just one amoung many. 
   The time will come when someone will send you a patch and you will 
reject it and then the person will go off and make his/her own library.
Or someone will look at your work and say I can do better. Then we end
up with a bunch of libraries doing basically similiar things. Which one 
does the developer use then? We can't force them to use the "standard"
one. 
    The kernel really needs to be the only state machine for the hardware. 
Library developers will usually use the kernel standard interfaces. 

This library will also be responsible to broadcast, possibly via
D-BUS, events like screen hotplug and mode changes. We are thinking
about interfacing the fd.o xserver on this among others. It will
not do anything about rendering though.

I like to see the D-BUS pick up these events :-) It would come in handy 
for the JVMs I work on.
 

That leads to another issue which is arbitration at the low level
driver between rendering & mode switching. That should be done by
the kernel driver at some point, we need to merge the mode setting
driver (fbdev) and the command queue diver (DRI). 

I agree they have to be merged.

Probably moving 
some of the higher level mode management out of the kernel driver
down to this userland library.

Bad idea.



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

   I think this is a bad idea. This has been tried before. In the 
opensource community there is no such a thing as a standard library. 

On the other hand, things like dbus are low-level and slowly getting
used by everyone... we also have the libc :)

 ..../....

    The kernel really needs to be the only state machine for the hardware. 
Library developers will usually use the kernel standard interfaces. 

I don't fully agree. The kernel will do the actual HW banging, but
we want things like EDID overrides per monitor models, persistent
configuration saved to storage etc... all of that beeing pretty
nasty to do in the kernel.

quoted

Probably moving 
some of the higher level mode management out of the kernel driver
down to this userland library.

Bad idea.

I have mixed feeling on that. Keith Packard seem to prefer the library
approach. I don't know for sure what Linus prefers here. Currently, I
feel we are trying to do too much in the kernel, and that will become
increasingly painful to manage as we get multiple head & geometry stuff
getting in the picture.

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

quoted

   I think this is a bad idea. This has been tried before. In the 
opensource community there is no such a thing as a standard library. 

On the other hand, things like dbus are low-level and slowly getting
used by everyone... we also have the libc :)

Well now that we have one input api that can happen. Of course with 
graphics its much more diverse with what you can do. That is one of the 
reasons for so many graphics libraries. It would be really hard to write
a one size fits all library when it comes to graphics.

quoted

    The kernel really needs to be the only state machine for the hardware. 
Library developers will usually use the kernel standard interfaces. 

I don't fully agree. The kernel will do the actual HW banging, but
we want things like EDID overrides per monitor models, persistent
configuration saved to storage etc... all of that beeing pretty
nasty to do in the kernel.

By state machine I mean the physical hardware state. If it's hardware 
access then it should be in the kernel. Note I'm refering to mode setting 
not acceleration. Now EDID overrides per monitor model and saving the 
state to disk is different. That should be userland. 

I have mixed feeling on that. Keith Packard seem to prefer the library
approach. I don't know for sure what Linus prefers here. Currently, I
feel we are trying to do too much in the kernel, and that will become
increasingly painful to manage as we get multiple head & geometry stuff
getting in the picture.

I think we are fine for whats in the kernel. As for multiple head and 
geometry stuff its not that hard if done right. I have been using 
multi-head systems for years. I have multip desktop systems for years!!!





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Well now that we have one input api that can happen. Of course with 
graphics its much more diverse with what you can do. That is one of the 
reasons for so many graphics libraries. It would be really hard to write
a one size fits all library when it comes to graphics.

Note that I am NOT talking about a graphics library. This has NO
BUSINESS doing any kind of rendering. It's only the userland interface
to the underlying kernel drivers as far as mode switching & geometry
is concerned. That's _ALL_. In the same  was as libGL is the userland
interface to DRI, or iptables the userlnad interface to netfilter,
etc...
 

By state machine I mean the physical hardware state. If it's hardware 
access then it should be in the kernel. Note I'm refering to mode setting 
not acceleration. Now EDID overrides per monitor model and saving the 
state to disk is different. That should be userland. 

I agree. The HW access is done in kernel space. That's even true for
acceleration actually. You are mixing things. What I'm taking about
is exactly that: The userland library gets the various EDID & other
probing informations coming from the kernel drivers. It does the various
policy decisions on mode setting, it provides the API for userland to
deal with mode setting & monitor placement (what I call geometry)
and saving/restoring of configurations. The actual banging of the mode
to the HW is done by the kernel driver though. (The card specific back
end of the library probably builds either a mode description or a
register list and pass that to the kernel driver).

I think we are fine for whats in the kernel. As for multiple head and 
geometry stuff its not that hard if done right. I have been using 
multi-head systems for years. I have multip desktop systems for years!!!

I have been using multi head systems for years and I've seen how good
it can be, but also a bunch of the pitfalls when trying to design a
driver for it. If it was that easy, we would have had the right support
in fbdev for ages. We don't.

Ben.



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Note that I am NOT talking about a graphics library. This has NO
BUSINESS doing any kind of rendering. It's only the userland interface
to the underlying kernel drivers as far as mode switching & geometry
is concerned. That's _ALL_. In the same  was as libGL is the userland
interface to DRI, or iptables the userlnad interface to netfilter,
etc...

..snip..

That cool. Sorry, email is so limited sometimes in details. I agree with 
you 100%.
  

quoted

I think we are fine for whats in the kernel. As for multiple head and 
geometry stuff its not that hard if done right. I have been using 
multi-head systems for years. I have multip desktop systems for years!!!

I have been using multi head systems for years and I've seen how good
it can be, but also a bunch of the pitfalls when trying to design a
driver for it. If it was that easy, we would have had the right support
in fbdev for ages. We don't.

True it is not to easy but I have worked on it. I'm glad to see the input 
api and most of the fbdev stfuff go in. It laid down the need foundation 
for mulitdesktop systems.

On Wed, 2004-02-25 at 12:21, James Simmons wrote:

quoted

Sure, hopefully fbdev drivers became more 'intelligent', with just a

echo "1024x768x16-75" > /sys/class/fbdev/0/geometry

they will compute internally the timings or get it from EDID and
glad the user with something correct for the hardware.

cat /sys/class/fbdev/0/modes

will give you the modes supported by the card.

Yes.

Note that "the modes supported by the card" means nothing.

They depend on something fundamentally dynamic, which is what is
connected to what output, mixed with some card-spcific limitations
(like bandwidth limitations when using 2 very big monitors, vram
limitations, etc...)

You can not really know a-priori what modes will be available for
sure. You can provide a list of modes that are considered as valid
for a given output, but the whole mode setting scheme cannot be
anything else but non-deterministic. You setup a global configuration,
send it down the driver, and obtain a new configuration which may or
may not be what you asked for.

I'm trying to address the API issues as part of the userland library
I'm talking about in the other email. The actual interface to the
kernel driver should ultimately be hidden, and eventually private
between card-specific kernel driver and card-specific module in
the userland API.

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, Feb 25, 2004 at 12:29:52PM +1100, Benjamin Herrenschmidt wrote:

On Wed, 2004-02-25 at 12:21, James Simmons wrote:

quoted

quoted

Sure, hopefully fbdev drivers became more 'intelligent', with just a

echo "1024x768x16-75" > /sys/class/fbdev/0/geometry

they will compute internally the timings or get it from EDID and
glad the user with something correct for the hardware.

cat /sys/class/fbdev/0/modes

will give you the modes supported by the card.

Yes.

Note that "the modes supported by the card" means nothing.

They depend on something fundamentally dynamic, which is what is
connected to what output, mixed with some card-spcific limitations
(like bandwidth limitations when using 2 very big monitors, vram
limitations, etc...)

You can not really know a-priori what modes will be available for
sure. You can provide a list of modes that are considered as valid
for a given output, but the whole mode setting scheme cannot be
anything else but non-deterministic. You setup a global configuration,
send it down the driver, and obtain a new configuration which may or
may not be what you asked for.

Hmm, how does winxp and macosx get their respectives video modes,
what is missing in fbdev for that? MacOSX always gives you valid modes
including refresh rates per adaptor/monitor, WinXP always give you valid
modes and valid refresh rates for the video card, you actually
'Apply' to test, most of the time it simply works.

I'm trying to address the API issues as part of the userland library
I'm talking about in the other email. The actual interface to the
kernel driver should ultimately be hidden, and eventually private
between card-specific kernel driver and card-specific module in
the userland API.

Great! i think your idea is great, does that library will be xserver
dependant or will be an independent lib so others projects like mine
could benefit from it?  Any bits somewhere?  This alone could boom
and revolutionize the graphics solutions for linux.  A step in the
right direction for "World Domination" in the desktop field.

-otto



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Hmm, how does winxp and macosx get their respectives video modes,
what is missing in fbdev for that? MacOSX always gives you valid modes
including refresh rates per adaptor/monitor, WinXP always give you valid
modes and valid refresh rates for the video card, you actually
'Apply' to test, most of the time it simply works.

They do the same as I described. As you wrote, it works most of the
time. That's the whole point. You submit a "proposed" configuration
and gets back something .... most of the time, you do get back what
you asked. But you _might_ not. In some cases, what will happen is
that the "other" head will be affected. For example, enabling
mirroring on a non-4.3 LCD laptop like a titanium powerbook while
having a 4.3 display (CRT) plugged on the second output will cause
the LCD to be resized to a 4.3 ratio in MacOS.
So in this case, you get _more_ than what you asked.

Great! i think your idea is great, does that library will be xserver
dependant or will be an independent lib so others projects like mine
could benefit from it?  Any bits somewhere?  This alone could boom
and revolutionize the graphics solutions for linux.  A step in the
right direction for "World Domination" in the desktop field.

It's meant to be independant of anything else but the actual low
level driver model. Xserver would be one client, but others could
enter the game of course ;)

Ben.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be 
used for read and writes on /dev/fbX. Also it is used for software 
cursors. 

But if acceleration is not disabled you can't map the vmem and io regions.

quoted

By 'fixing the layer' i mean some simple things that could make fbdev
a real graphics solution for linux in the long term:

- fbdev_core (will handle the fbdev/sysfs registration, shared by all
              drivers, most important is the modes handling interface).

Pretty much done.

quoted

- fbdev_xxx  (driver for specific hw, it will only export the interesting
              bits like vmem, ioregs, will handle mmap stuff and ioctl's,
              video modes, no accel of any kind).

Have it.

quoted

- fbdev_xxx_accel (acceleration hooks if any for xxx driver, optional module)

We need it for the above reasons.

quoted

- fbdev_con  (handle console -- already modular in 2.6, will use accel hooks
              if not NULL, optional).

We always need the accel hooks. Some how we have to draw the fonts.

Ok, i get your point about accel.  My point is that accel for userland is
already there in Mesa-solo with the DRI accelerated drivers or with directfb,
we just need the basic linux graphics infrastructure with the following
functionality so specialized libraries (like the above) integrate nicely with
the fbdev.

In summary:

1. Card identification.
	A simple bus_id will do this hopefully on any platform.
2. Port identification.
	I don't think exists a form to determine this with the current
	functionality, MacOSx excells in this area.
3. Modes list supported by the card per graphics port.
	As BenH noted, filtered by constraints like mem bandwitdh, etc.
	hopefully using EDID or any other monitor info present.
4. Memory mappings.
	We can currently map the vmem and io regions in userspace.  It
	current exists problems with highmem but in short it simply works
	for dumb chips or programable chips so specialized libs (like
	mesa-solo) can do a decent job.
5. sysfs interface.
	So we can control the behavior with libsysfs to change video modes, get
	card/monitor info, etc.
6. DRM or card's command queue.
	For use in the mentioned DRI drivers or any other project based on that.
7) read/write/other_fs_ops/ioctl.
	So current fbdev software works without problems.
8) Graphics console.

1) is trivial.
2) 3) 5) and 6) is what needs work or is lacking currently.
4) and 7) 8) are already done and was a major step for graphics on linux in
   its time.

I am by no means a graphics expert like you or BenH but i think the mentioned
above should express general userland needs.

quoted

We have now with 2.6 a good input and sound layers.  Just by fixing
the graphics layer many interesting userland projects could be born.

I agree. The graphics layer is the last frontier.

Yes, it will bring Linux on the Desktop an unavoidable reality, being part
this basic functionality of the kernel is what one expects from a modern system
but many could argument that is job for userland libs, probably true, anyway
we need a (preferably graphics) console early in the boot process.

-otto



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Tue, 24 Feb 2004, Otto Solares wrote:

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

quoted

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be
used for read and writes on /dev/fbX. Also it is used for software
cursors.

But if acceleration is not disabled you can't map the vmem and io regions.

I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
time. So I see no problem disabling accelerated read/write while mmio is
mapped.

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 is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:

On Tue, 24 Feb 2004, Otto Solares wrote:

quoted

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

quoted

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be
used for read and writes on /dev/fbX. Also it is used for software
cursors.

But if acceleration is not disabled you can't map the vmem and io regions.

I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
time. So I see no problem disabling accelerated read/write while mmio is
mapped.

I wonder about X though. It uses mmio for accels (in the non fbdev case
though) and needs to map the memory area for fallback case, like the non
supported bressenham lines on permedia 2/3 for example. Altough it is
possible that the fact that X does its own mapping, and anyway, has very
little interaction with fbcon and fbdev anyway.

Friendly,

Sven Luther



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, 25 Feb 2004, Sven Luther wrote:

On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:

quoted

On Tue, 24 Feb 2004, Otto Solares wrote:

quoted

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

quoted

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be
used for read and writes on /dev/fbX. Also it is used for software
cursors.

But if acceleration is not disabled you can't map the vmem and io regions.

I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
time. So I see no problem disabling accelerated read/write while mmio is
mapped.

I wonder about X though. It uses mmio for accels (in the non fbdev case
though) and needs to map the memory area for fallback case, like the non
supported bressenham lines on permedia 2/3 for example. Altough it is
possible that the fact that X does its own mapping, and anyway, has very
little interaction with fbcon and fbdev anyway.

That's mmap(2) of the frame buffer, not read(2)/write(2).

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 is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
time. So I see no problem disabling accelerated read/write while mmio is
mapped.

Good point!



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:

On Tue, 24 Feb 2004, Otto Solares wrote:

quoted

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

quoted

On the other side i see a lot of effort in the fbdev acceleration,
it is nice but that effort should be better spent on fixing the layer,
imo, the only user for acceleration is fbcon, any userland app that
use fbdev disables that acceleration so it can map the vmem and ioregs,
and do it's own voodoo if it wants acceleration.  That acceleration
is not "exported" to user space.  I am working in a open source project
that uses mesa-solo with fbdev and many limitations from the layer
itself have been seen.

That is true so far for fillrect and copyarea functions. Imageblit will be
used for read and writes on /dev/fbX. Also it is used for software
cursors.

But if acceleration is not disabled you can't map the vmem and io regions.

I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
time. So I see no problem disabling accelerated read/write while mmio is
mapped.

Exactly, that's the whole point, if you want userland accel you must disable
kernel land accel.  That's was my question against acceleration work inside
the kernel.  Nobody use it in userland and is the stability devil in fbdev.
If you want acceleration in userland there is mesa-solo or directfb or console-sdl.

In short acceleration belongs to specialized libs not the kernel.

Why accel it is needed for font drawing?, i am pretty sure my 8bit video old
sparc doesn't have any accel and is pretty capable for drawing fonts.

-otto



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Exactly, that's the whole point, if you want userland accel you must disable
kernel land accel.  That's was my question against acceleration work inside
the kernel.  Nobody use it in userland and is the stability devil in fbdev.
If you want acceleration in userland there is mesa-solo or directfb or console-sdl.

In short acceleration belongs to specialized libs not the kernel.

Why accel it is needed for font drawing?, i am pretty sure my 8bit video old
sparc doesn't have any accel and is pretty capable for drawing fonts.

Because we are going to run into graphics hardware that don't have 
framebuffers. The solution is the one we are approaching now. That fbcon 
be a client like userland apps to the accel engine. You will see it will 
all work out :-)



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Thu, Feb 26, 2004 at 07:45:47PM +0000, James Simmons wrote:

quoted

Exactly, that's the whole point, if you want userland accel you must disable
kernel land accel.  That's was my question against acceleration work inside
the kernel.  Nobody use it in userland and is the stability devil in fbdev.
If you want acceleration in userland there is mesa-solo or directfb or console-sdl.

In short acceleration belongs to specialized libs not the kernel.

Why accel it is needed for font drawing?, i am pretty sure my 8bit video old
sparc doesn't have any accel and is pretty capable for drawing fonts.

Because we are going to run into graphics hardware that don't have 
framebuffers. The solution is the one we are approaching now. That fbcon 
be a client like userland apps to the accel engine. You will see it will 
all work out :-)

Oh, that fact changes everything :)

-otto



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

But if acceleration is not disabled you can't map the vmem and io regions.

That whole management needs to be reworked. Properly replaced with DRI.

I am by no means a graphics expert like you or BenH but i think the mentioned
above should express general userland needs.

I agree. Its getting there :-)
 



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, 2004-02-25 at 04:15, Otto Solares wrote: 

4. Memory mappings.
	We can currently map the vmem and io regions in userspace.  It
	current exists problems with highmem but in short it simply works
	for dumb chips or programable chips so specialized libs (like
	mesa-solo) can do a decent job.

I hope Mesa-solo doesn't bang the chip directly, does it? That would
mean root only.

And while we're brainstorming... :)

I'm not sure being able to map the whole video RAM is a good idea in the
long run either; at some point we probably need a centralized memory
manager, and I think ideally it should map the allocated regions
separately (which could allow for moving them between video RAM, GART
and system RAM transparently, e.g.) and only allow to use them for
acceleration by opaque handles (via the DRM or whatever). This would be
quite a lot of stuff in the kernel, but I'm not sure it can be done
safely in user space...


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

On Mon, 23 Feb 2004 11:53 am, Benjamin Herrenschmidt wrote:

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

Been around forever and a day. RedHat getty's clear the screen, which tends to 
remove the unscrollable region that the logo sits in. Debian doesn't, so it's 
much more noticable (and always has been).

This might be best done thru userspace, as having the logo and other graphics 
sitting at the top of the screen through the boot process (eg: sysv init 
scripts, etc) within an unscrollable region can be useful. I know that the 
boot-icons package in Debian actually relies on this behaviour. Perhaps you 
could provide an option in the kernel config to change this default 
behaviour, for those that want it?

If it's possible to unlock this region so that it scrolls again from userspace 
(ie: not resetting/clearing it, just unlocking it), then it's just a simple 
matter of checking wether the current console is an fb device, and if it is, 
making it unlock the scrolling region. In Debian, this could be done 
in /etc/init.d/rmnologin, or even in /etc/profile if someone would rather it 
done after login.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Tue, 24 Feb 2004, Stuart Young wrote:

On Mon, 23 Feb 2004 11:53 am, Benjamin Herrenschmidt wrote:

quoted

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully working
with vi.

Been around forever and a day. RedHat getty's clear the screen, which tends to
remove the unscrollable region that the logo sits in. Debian doesn't, so it's
much more noticable (and always has been).

This might be best done thru userspace, as having the logo and other graphics
sitting at the top of the screen through the boot process (eg: sysv init
scripts, etc) within an unscrollable region can be useful. I know that the
boot-icons package in Debian actually relies on this behaviour. Perhaps you
could provide an option in the kernel config to change this default
behaviour, for those that want it?

If it's possible to unlock this region so that it scrolls again from userspace
(ie: not resetting/clearing it, just unlocking it), then it's just a simple
matter of checking wether the current console is an fb device, and if it is,
making it unlock the scrolling region. In Debian, this could be done
in /etc/init.d/rmnologin, or even in /etc/profile if someone would rather it
done after login.

There should be an ANSI escape sequence for resetting the scroll region. Just
send that to the 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


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Tue, 24 Feb 2004 07:36 pm, Geert Uytterhoeven wrote:

On Tue, 24 Feb 2004, Stuart Young wrote:

quoted

On Mon, 23 Feb 2004 11:53 am, Benjamin Herrenschmidt wrote:

quoted

 - Logo problems. When booting with a logo, then going to getty, the
logo doesn't get erased until we actually switch to another console (or
reset the console). At this point, using things like vi & scrolling up
doesn't work properly. Actually, last time I tried, I had to switch
back & forth twice before my console that had the logo got fully
working with vi.

If it's possible to unlock this region so that it scrolls again from
userspace (ie: not resetting/clearing it, just unlocking it), then it's
just a simple matter of checking wether the current console is an fb
device, and if it is, making it unlock the scrolling region. In Debian,
this could be done in /etc/init.d/rmnologin, or even in /etc/profile if
someone would rather it done after login.

There should be an ANSI escape sequence for resetting the scroll region.
Just send that to the console.

Yup there is. It's Esc [r , however this also returns the cursor to the top of 
the screen. You can use Esc [s & Esc [u to save and restore the current 
cursor position, so it's just a matter of putting them around it thus:
 Esc [s Esc [r Esc [u

Or with echo (in a bash script - \\'s to escape it from the shell):
 echo -ne \\033[s\\033[r\\033[u

Now there is a problem with this solution: This leaves the logo (and any 
boot-time drawn graphics in the unscrollable region) on the screen. When text 
scrolls up the screen, these graphics do not scroll, and are only removed 
when a character overwrites the graphics position on the screen. If you have 
a number of graphics on the screen (or a machine with a number of processors, 
and therefore a number of tux logos), you'll find that you end up with 
spurious graphical artifacts left on the display where the text hasn't 
directly overwritten the image.

Now you'd think that you could easily just wipe (n) lines off the screen, 
probably using ansi escape sequences. Well it sort of works, but then you 
need to know how big the logo is, how big the font is (as you're working with 
an ascii to graphical representation), and just how much of the screen to 
wipe, to get it right for all the various fbcon display arrangements. While 
the info might be available to userspace to figure this out, it stops being 
simple.

Probably could just talk to the fb driver directly (from the shell) and wipe 
that section of screen. Fun fun fun... Hrm.. Time to look into it.

Of course, you could just clear the screen.....

Note: Fixing this in a binary is pretty much a no-no. How many dists will want 
to add another binary to their systems, or patch something like getty simply 
to fix a display artifact? I'm guessing pretty close to the 0 mark.

--
 Stuart Young - sgy-lkml@amc.com.au is specifically for LKML and related email



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

On Wed, 2004-02-25 at 08:14, Stuart Young wrote: 

On Tue, 24 Feb 2004 07:36 pm, Geert Uytterhoeven wrote:

quoted

There should be an ANSI escape sequence for resetting the scroll region.
Just send that to the console.

Yup there is. It's Esc [r , however this also returns the cursor to the top of 
the screen. You can use Esc [s & Esc [u to save and restore the current 
cursor position, so it's just a matter of putting them around it thus:
 Esc [s Esc [r Esc [u

Or with echo (in a bash script - \\'s to escape it from the shell):
 echo -ne \\033[s\\033[r\\033[u

Now there is a problem with this solution: This leaves the logo (and any 
boot-time drawn graphics in the unscrollable region) on the screen.

Should it? :)


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer