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

[Linux-fbdev-devel] [patch] Re: Framebuffer, mmap(), hanging in D state, root FS unmount failure.

[Andrew M. <ak...@zi...>]

Andrew Morton wrote:
> 
> However I don't see why _any_ architecture wants framebuffer contents
> to be included in core files.  It sounds risky.
> 
> So the setting of VM_IO could be simply hoisted outside the forest
> of ifdefs.  Comments, anyone?

Well nobody has objected....

The patch marks fbdev mappings as VM_IO for *all* architectures.

This prevents a kernel deadlock (mmap_sem) which occurs on x86 when a
program which has mmapped an fbdev tries to dump core.


--- linux-2.4.18-pre1/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Sun Dec 30 00:23:15 2001
@@ -576,12 +576,13 @@ fb_mmap(struct file *file, struct vm_are
 		return -EINVAL;
 	off += start;
 	vma->vm_pgoff = off >> PAGE_SHIFT;
+	/* This is an IO map - tell maydump to skip this VMA */
+	vma->vm_flags |= VM_IO;
 #if defined(__sparc_v9__)
 	vma->vm_flags |= (VM_SHM | VM_LOCKED);
 	if (io_remap_page_range(vma->vm_start, off,
 				vma->vm_end - vma->vm_start, vma->vm_page_prot, 0))
 		return -EAGAIN;
-	vma->vm_flags |= VM_IO;
 #else
 #if defined(__mc68000__)
 #if defined(CONFIG_SUN3)
@@ -607,8 +608,6 @@ fb_mmap(struct file *file, struct vm_are
 	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;
 #elif defined(__arm__)
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-	/* This is an IO map - tell maydump to skip this VMA */
-	vma->vm_flags |= VM_IO;
 #elif defined(__sh__)
 	pgprot_val(vma->vm_page_prot) &= ~_PAGE_CACHABLE;
 #else


-

[Linux-fbdev-devel] dj tree.

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

Hi folks!

   I talked to Dave Jones a little bit ago about accepting patches. As we
know Linus has been busy with the block layer and hasn't been taking abny
other patches. I like to see our work get a larger audience. So David has
agreed to this. So Geert and Vojtech I like to push our work to the dj
tree. Note the ruby tree will remain against the standard Linus tree but
the dj tree will end up closer to the ruby tree. Eventually it will sync
over to Linus tree. 
   I already have sent patchs for the new fbdev api. The one you blessed
Geert. I sent some of tty stuff as well. So I like to see everyone here
agree to use the dj tree for our work. 

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [Linux-fbdev-devel] Two bug fixes for cyber2000fb

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

On 29 Dec 2001, Johan Bolmsjo wrote:
> 2) var.bits_per_pixel returned is 15 for RGB1555 and RGB565 modes.
>    var.bits_per_pixel should be 16 for both these modes. One should
>    then use the colour bit masks to see which mode is used.
> 
> I'm not 100% sure on my reasoning on 2) but I think it has been up
> on the list before.

Yes, var.bits_per_pixel must be the physical size of one pixel. The separation
in different color channels must be reflected in the color bitfields.

> Is there any test program that tests all frame-buffer modes to detect
> ill behaviours in frame-buffer drivers? Not all drivers seem to work
> the same way..

CVS module fbtest from project linux-fbdev at SourceForge.

Someone should fill in the (currently empty) routines {fix,var}_validate(), and
some tests to test all (how do you do that?) frame-buffer modes.

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

[Linux-fbdev-devel] Re: Framebuffer, mmap(), hanging in D state, root FS unmount failure.

[Andrew M. <ak...@zi...>]

Mark J Roberts wrote:
> 
> #include <assert.h>
> #include <sys/mman.h>
> #include <fcntl.h>
> int main(void)
> {
>         char *p;
>         assert((p = mmap(0, 1, PROT_READ|PROT_WRITE, MAP_SHARED, open("/dev/fb/0", O_RDWR), 0)) != MAP_FAILED);
>         p[4096] = 0; /* this hangs */
>         return 0;
> }
> 
> When I run this on my 2.4.17rc2aa2 kernel with a Voodoo3000
> framebuffer, the process hangs forever in D state. ps and top will
> then hang the same way when they read the /proc/pid files for the
> hung process. And my root filesystem won't unmount.
> 

OK, the framebuffer driver is failing to mark the mmapped vma as
VM_IO, so the kernel is trying to dump the framebuffer device
to the core file, takes a recursive fault and deadlocks.

Simplest possible fix is to mark the framebuffer as not dumpable
for x86.

--- linux-2.4.18-pre1/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Fri Dec 28 16:18:05 2001
@@ -600,6 +600,7 @@ fb_mmap(struct file *file, struct vm_are
 #elif defined(__alpha__)
 	/* Caching is off in the I/O space quadrant by design.  */
 #elif defined(__i386__) || defined(__x86_64__)
+	vma->vm_flags |= VM_IO;
 	if (boot_cpu_data.x86 > 3)
 		pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
 #elif defined(__mips__)


However I don't see why _any_ architecture wants framebuffer contents
to be included in core files.  It sounds risky.

So the setting of VM_IO could be simply hoisted outside the forest
of ifdefs.  Comments, anyone?

-

Re: [Linux-fbdev-devel] Error in radeonfb.c

[Ani J. <aj...@sh...>]

Version 0.1.3 of the driver will be in 2.4.18-pre1, this includes a host
of fixes and adds support for the new 7500 and 8500 boards.


ani

On Wed, 26 Dec 2001, Bryan Stillwell wrote:

> Recently I bought a Radeon 8500 (the pci id is 514c, which isn't
> detected by the 2.4.17 kernel) and was able to get some framebuffer
> support working, but it's rather flaky.  I didn't have any compilation
> problems like the previous guy though.  However, I have a few questions
> for whoever can answer them:
>
> o Who has an 8500 and is working on improving it so that it is more
>   stable?
> o Where can I find the latest tree?
> o Has anyone put together a website with a collection of the available
>   documentation?
>
> Thanks,
> Bryan
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

Re: [Linux-fbdev-devel] Error in radeonfb.c

[Bryan S. <br...@bo...>]

On Tue, Dec 25, 2001 at 06:43:59PM +0100, Benjamin Herrenschmidt wrote:
>I think radeonfb is very outdated in the main tree. I suppose the new
>version will get in Marcelo tree during 2.4.18 along with other PPC
>stuffs.

Hey Ben,

Recently I bought a Radeon 8500 (the pci id is 514c, which isn't
detected by the 2.4.17 kernel) and was able to get some framebuffer
support working, but it's rather flaky.  I didn't have any compilation
problems like the previous guy though.  However, I have a few questions
for whoever can answer them:

o Who has an 8500 and is working on improving it so that it is more
  stable?
o Where can I find the latest tree?
o Has anyone put together a website with a collection of the available
  documentation?

Thanks,
Bryan

Re: [Linux-fbdev-devel] Error in radeonfb.c

[Benjamin H. <be...@ke...>]

>Hi!
>
>I'm looking for the maintainer of frame buffer code in the 2.4 kernel.
>
>Since I'm an (in the meantime *VERY* disappointed) owner of a Dell Lati=
tude
>C610 I have to fight with that beast. It has a radeon M6 LY chip inside=
,
>and that stupid thing doesn't work at all.
>
>In order to get that #*&%$! machine working with X11 I tried to compile=
 a
>new kernel. I found two typos in the frame buffer code (Linux 2.4.17):
>
>In radeonfb.c, line 1178:
>                case 786:
>
>I think 768 sounds better ...
>
>In radeonfb.c, line 1410:
>#ifdef FBCON=5FHAS=5FCFB32
>
>this should be
>#ifdef FBCON=5FHAS=5FCFB24
>
>otherwise it does not compile.
>
>The reason why I'm disappointed with that Dell box is that even with th=
ose
>changes the only result I get is a hangup, a real complete one. It happ=
ens 
>at the moment when frame buffer code get's executed.
>
>If somebody has any ideas about that, he or she is *VERY* welcome.
>
>There=B4s a diff file with those vahnges attached.

I think radeonfb is very outdated in the main tree. I suppose the new
version will get in Marcelo tree during 2.4.18 along with other PPC
stuffs.

Ben.

[Linux-fbdev-devel] Error in radeonfb.c

[<wur...@ne...>]

Hi!

I'm looking for the maintainer of frame buffer code in the 2.4 kernel.

Since I'm an (in the meantime *VERY* disappointed) owner of a Dell Latitude
C610 I have to fight with that beast. It has a radeon M6 LY chip inside,
and that stupid thing doesn't work at all.

In order to get that #*&%$! machine working with X11 I tried to compile a
new kernel. I found two typos in the frame buffer code (Linux 2.4.17):

In radeonfb.c, line 1178:
                case 786:

I think 768 sounds better ...

In radeonfb.c, line 1410:
#ifdef FBCON_HAS_CFB32

this should be
#ifdef FBCON_HAS_CFB24

otherwise it does not compile.

The reason why I'm disappointed with that Dell box is that even with those
changes the only result I get is a hangup, a real complete one. It happens 
at the moment when frame buffer code get's executed.

If somebody has any ideas about that, he or she is *VERY* welcome.

There´s a diff file with those vahnges attached.

best wishes

Hannes

Johannes Gritsch
Vienna, Austria
-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: [Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

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

On Mon, Dec 24, 2001 at 10:08:07AM -0600, Carl Wilhelm Soderstrom wrote:
> On Mon, Dec 24, 2001 at 10:43:26AM +0100, Geert Uytterhoeven wrote:
> > Because you have a RAGE XL, which isn't supported that well yet, and which
> > doesn't seem to be initialized by the BIOS (cfr. `512K SGRAM', which I doubt
> > you have).
> > 
> > Unlike matroxfb (on some cards, not G450), atyfb cannot initialize cards from
> > scratch yet.
> 
> aha. I see. well, this is what I get for grabbing the cheapest vid board at
> the store. :) 

In that case:
(1) Get kernel 2.4.17
(2) Download ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-2.4.17.gz
(3) Apply patch (zcat mga-2.4.17.gz | (cd /usr/src/linux-2.4.17; patch -p1))
(4) Run kernel configuration tool and answer yes for G100-G550 support,
    G450 dualhead support, and for Matrox /proc interface support. You can
    answer yes to something else too, but these three are mandatory.
(5) Make sure that BIOS uses ATI for its output
(6) Reboot and pray
(7) You should get nice picture on ATI (either from BIOS, vgacon or atyfb)
    and nice picture on both G450 heads (though you'll see nothing on them
    except color dots after bootup; con2fb & matroxset is your friend)
(8) If (7) did not happen, send me contents of all
    /proc/driver/mga/fb*/* you'll find (you should find one 'bios' and
    one 'pins' for each Matrox video card in your box).

And I have no idea why second head picture is on different place when you
use fbset before X.
						Petr Vandrovec
						van...@vc...

Re: [Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

[Carl W. S. <ch...@re...>]

On Mon, Dec 24, 2001 at 10:43:26AM +0100, Geert Uytterhoeven wrote:
> Because you have a RAGE XL, which isn't supported that well yet, and which
> doesn't seem to be initialized by the BIOS (cfr. `512K SGRAM', which I doubt
> you have).
> 
> Unlike matroxfb (on some cards, not G450), atyfb cannot initialize cards from
> scratch yet.

aha. I see. well, this is what I get for grabbing the cheapest vid board at
the store. :) 

btw, I read your paper on the Linux 2.2 framebuffer device, Mr.
Uytterhoeven; excellent piece. very good introduction to the whole matter.
:)

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

Re: [Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

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

On Mon, 24 Dec 2001, Carl Wilhelm Soderstrom wrote:
> > > And after I looked into your dmesg - are you sure that
> > > it does not die due to atyfb? 
> > 	yeah, that's a possibility. I'll build a new kernel without that.
> 	
> 	the ATI framebuffer support seems to have been the issue. without
> that; everything works reasonably fine.
> 	this of course leads to the question; why does the addition of an
> ati framebuffer cause these problems?

Because you have a RAGE XL, which isn't supported that well yet, and which
doesn't seem to be initialized by the BIOS (cfr. `512K SGRAM', which I doubt
you have).

Unlike matroxfb (on some cards, not G450), atyfb cannot initialize cards from
scratch yet.

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] bugs in G450 framebuffer console under linux 2.4.17

[Carl W. S. <ch...@re...>]

> > And after I looked into your dmesg - are you sure that
> > it does not die due to atyfb? 
> 	yeah, that's a possibility. I'll build a new kernel without that.
	
	the ATI framebuffer support seems to have been the issue. without
that; everything works reasonably fine.
	this of course leads to the question; why does the addition of an
ati framebuffer cause these problems?


> > Fix your /etc/fbset.modes. Secondary head (as documented) cannot do 8bpp,
> > it can do only 16bpp and 32bpp.
> 	hmm, looks like I don't have an /etc/fbset.modes. will look into
> that.
	I think you meant /etc/fb.modes. yes, I do have that.
	giving the -depth 16 option in fbset makes it set the display
properly. it would be nice to give a more helpful error message in
situations like this; but I expect this is a problem that's not entirely
trivial to generalize; since it depends on the graphics card's limitations.

I did notice one more bug:
if one has a framebuffer for the G450's second head, and uses fbset to
operate upon it before starting X; the image displayed on that screen once X
is started, will be offset to the right by about an inch. if one doesn't use
fbset before starting X (this is just plain MGA X, not fbdev); then the
image appears in the proper place.
	is this an issue with X, or the framebuffer? I'm going to suspect X,
since it ought to reset things properly before starting; but I know that
G450 support in X is pretty shaky in places (DRI is buggy), and
unfortunately there isn't an active maintainer that I've seen. :(

thanks much for the help!

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

Re: [Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

[Carl W. S. <ch...@re...>]

> Which option you need to specify to 'video='? You are probably using
> vesafb together with matroxfb, or matroxfb together with vga16fb. It
> does not work. 
	no, I recompiled my kernel after reading the docs, and turned off
vesafb. 

> And after I looked into your dmesg - are you sure that
> it does not die due to atyfb? 
	yeah, that's a possibility. I'll build a new kernel without that.

> And G450 driver in kernel cannot initialize
> G450 from scratch (== you must use matrox as primary device, initialized
> by BIOS).
	yep. the G450 is the primary display.
 
> Make sure that you are not running mga driver from Matrox.
	nope. running CVS X 4.1.99.1 (tho the library path is screwed up, so
that's why it's loading the 4.1.0 modules. I'll fix that before testing
more).

> Besides of that,
> it works everywhere else... Make sure that /proc/fb lists only Matrox
> framebuffers, not something else:
> 
> ppc:/cdrom# cat /proc/fb
> 0 MATROX VGA
> 1 MATROX CRTC2
> 
> And of course - are you sure that X do not die because of they are enabling
> legacy VGA, causing PCI parity error, and thus bringing your box down?
	so if I just set it to use the 'fbdev' driver, and not probe
(-configure), I've got a better chance of making it work?
	so why does framebuffer console + MGA X + G400 not cause problems on
the machines we have at work?

> Fix your /etc/fbset.modes. Secondary head (as documented) cannot do 8bpp,
> it can do only 16bpp and 32bpp.
	hmm, looks like I don't have an /etc/fbset.modes. will look into
that.

> Fix your /dev/fb* nodes. If you are not running 2.2.x kernels, /dev/fb1
> should be  29,1, /dev/fb2 should be 29,2 and so on.
	ok. will do. 

> Remove either atyfb + ATI or matroxfb + G450 from your box, and try again...
	thanks much! will build another kernel with fewer things, and see
what breaks then.

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

Re: [Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

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

On Sun, Dec 23, 2001 at 05:05:08PM -0600, Carl Wilhelm Soderstrom wrote:
> 1. if one doesn't specify a video= option at boot time; the console will
> hang, and the machine soon locks up. (I know it is locked because my
> LCD panel attached to the serial port displays no information, and I tried
> pinging it across the network).

Which option you need to specify to 'video='? You are probably using
vesafb together with matroxfb, or matroxfb together with vga16fb. It
does not work. And after I looked into your dmesg - are you sure that
it does not die due to atyfb? And G450 driver in kernel cannot initialize
G450 from scratch (== you must use matrox as primary device, initialized
by BIOS).

> 2. if one does boot; and then tries to start X (even XFree86 -configure as
> root), the system will lock completely. (tho I *did* have one successful
> startx once; and can't figure out why; since it always failed with a hard
> lockup otherwise). no X log is generated. it just locks immediately. the
> time that it did boot sucessfully; I couldn't see anything unusual in the
> log; tho I'm not an X programmer by any stretch. :)

Make sure that you are not running mga driver from Matrox. Besides of that,
it works everywhere else... Make sure that /proc/fb lists only Matrox
framebuffers, not something else:

ppc:/cdrom# cat /proc/fb
0 MATROX VGA
1 MATROX CRTC2

And of course - are you sure that X do not die because of they are enabling
legacy VGA, causing PCI parity error, and thus bringing your box down?

> 3. trying to use fbset on the second head of the G450 will fail, like so:
> root@steel:~# fbset -fb /dev/fb2 '640x480-75'
> ioctl FBIOPUT_VSCREENINFO: Invalid argument
> root@steel:~# fbset -fb /dev/fb2 '1280x1024-75'
> ioctl FBIOPUT_VSCREENINFO: Invalid argument
> root@steel:~# fbset -fb /dev/fb2 1280x1024-75 
> ioctl FBIOPUT_VSCREENINFO: Invalid argument

Fix your /etc/fbset.modes. Secondary head (as documented) cannot do 8bpp,
it can do only 16bpp and 32bpp.

> the first time you run this, it gives:
> Warning: Remapping obsolete /dev/fb* minor 64 to 2

Fix your /dev/fb* nodes. If you are not running 2.2.x kernels, /dev/fb1
should be  29,1, /dev/fb2 should be 29,2 and so on.

> what debugging information should I include? I saved a dmesg and my kernel
> .config file as well. rather than load the list with them, I put them at:
> http://copper.redchrome.org/~chrome/2.4.17-dmesg
> http://copper.redchrome.org/~chrome/2.4.17-config
> 
> I'm new to this list. How can I help debug this? 

Remove either atyfb + ATI or matroxfb + G450 from your box, and try again...
						Petr Vandrovec
						van...@vc...

[Linux-fbdev-devel] bugs in G450 framebuffer console under linux 2.4.17

[Carl W. S. <ch...@re...>]

I just built 2.4.17, and decided to try framebuffer support for my G450.
however, I found some bugs.

1. if one doesn't specify a video= option at boot time; the console will
hang, and the machine soon locks up. (I know it is locked because my
LCD panel attached to the serial port displays no information, and I tried
pinging it across the network).

2. if one does boot; and then tries to start X (even XFree86 -configure as
root), the system will lock completely. (tho I *did* have one successful
startx once; and can't figure out why; since it always failed with a hard
lockup otherwise). no X log is generated. it just locks immediately. the
time that it did boot sucessfully; I couldn't see anything unusual in the
log; tho I'm not an X programmer by any stretch. :)

3. trying to use fbset on the second head of the G450 will fail, like so:
root@steel:~# fbset -fb /dev/fb2 '640x480-75'
ioctl FBIOPUT_VSCREENINFO: Invalid argument
root@steel:~# fbset -fb /dev/fb2 '1280x1024-75'
ioctl FBIOPUT_VSCREENINFO: Invalid argument
root@steel:~# fbset -fb /dev/fb2 1280x1024-75 
ioctl FBIOPUT_VSCREENINFO: Invalid argument

the first time you run this, it gives:
Warning: Remapping obsolete /dev/fb* minor 64 to 2

nothing that I can see, goes into syslog about these issues.

options I'm booting with are:
2.4.17 video=matrox:vesa:0x11A

what debugging information should I include? I saved a dmesg and my kernel
.config file as well. rather than load the list with them, I put them at:
http://copper.redchrome.org/~chrome/2.4.17-dmesg
http://copper.redchrome.org/~chrome/2.4.17-config

I'm new to this list. How can I help debug this? 

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

[Linux-fbdev-devel] Framebuffer Landscape to Portrait Inversion

[D K R. <ra...@nc...>]

Hello All :

I am using an Assabet , I want to change the Landscape Picture format to
Portrait format. Can anyone point to me where in the framebuffer do I need
to make the changes ??

I am running a Linux 2.4.16 Kernel

Thanks in Advance ,
Raghu.

[Linux-fbdev-devel] 3 Security Problems

[Sottek, M. J <mat...@in...>]

I have discovered 3 security problems with the current framebuffers.
On some systems these may be serious issues with exploitable holes.

#1 The default mmap function allows any user with access to the
device to memory map whatever region is stored in mmio_base. On
chips with the ability to read arbitrary system memory this is a
hole that could easily allow root exploits. For systems with the
ability to write to arbitrary system memory this would be difficult
but possible to exploit. On almost all systems this could lead to
denial of service from locking the machine.
  In short, you cannot allow untrusted binaries to memory map mmio
regions for most graphics chips. Mapping of the MMIO regions has
to be limited to the root user.

#2 It seems most drivers are setting display->screen_base and
info->sysmem_size to reflect the entire available memory, not just
the framebuffer memory for the current mode. This could lead to
security problems for any driver that keeps command buffers or
double buffered registers in the framebuffer memory. Further it
is not possible at this time to set those values to indicate ONLY
the framebuffer because the fb X server incorrectly reads the
sysmem_size before setting the mode. For drivers that set
sysmem_size based on the actual framebuffer size X will get the
incorrect value.

#3 The current device read and write handlers do not account for
framebuffers with pitch != width. Reading from the device will
return all memory, even that outside the framebuffer.  This is
not an exploitable security hole but does raise the question as
to the correct behavior of read/write. I am ok with leaving it as
is, due to the fact that memory mapping the framebuffer would
give the same behavior. I do think that this has not been clearly
stated as the expected behavior.

-Matt

[Linux-fbdev-devel] fbgen question

[Jani M. <ja...@as...>]

Hi
I see fbgen_set_var doesn't call set_disp if the accel_flags field is
changed.So if I use fbset -accel it won't change the acceleratoin status.
Most of the drivers(which don't use fbgen) call set_disp form their
set_var.
I could explicitly call set_disp from my routines but I think that would
be uglier.Unless I'm missing something wouldn't such a patch help?

Jani

--- /usr/src/linux/drivers/video/fbgen.c	Wed Dec 19 11:34:55 2001
+++ fbgen.c	Wed Dec 19 11:34:42 2001
@@ -105,7 +105,8 @@
 {
     struct fb_info_gen *info2 = (struct fb_info_gen *)info;
     int err;
-    int oldxres, oldyres, oldbpp, oldxres_virtual, oldyres_virtual, oldyoffset;
+    int oldxres, oldyres, oldbpp, oldxres_virtual, oldyres_virtual, oldyoffset,
+	 oldaccel_flags;

     if ((err = fbgen_do_set_var(var, con == currcon, info2)))
 	return err;
@@ -116,12 +117,14 @@
 	oldyres_virtual = fb_display[con].var.yres_virtual;
 	oldbpp = fb_display[con].var.bits_per_pixel;
 	oldyoffset = fb_display[con].var.yoffset;
+	oldaccel_flags = fb_display[con].var.accel_flags;
 	fb_display[con].var = *var;
 	if (oldxres != var->xres || oldyres != var->yres ||
 	    oldxres_virtual != var->xres_virtual ||
 	    oldyres_virtual != var->yres_virtual ||
 	    oldbpp != var->bits_per_pixel ||
-	    oldyoffset != var->yoffset) {
+	    oldyoffset != var->yoffset ||
+	    oldaccel_flags != var->accel_flags) {
 	    fbgen_set_disp(con, info2);
 	    if (info->changevar)
 		(*info->changevar)(con);

Re: [Linux-fbdev-devel] Re: Framebuffer API with backlit displays

[<jg...@pa...>]

I don't much care what the range is.  0-10 seemed a bit low to us as a 
range, and the hardware we have today has a range of a couple hundred, 
though the highest values have to be avoided due to lifetime/power 
consumption.  So we arbitrarily matched what WinCE did and limited the 
the high value to what we understood the limits on frontlight lifetime 
dictated, and rescaled to match.

Moral: most/all hardware will have to have a simple rescaling/limit testing 
anyway, so it is pretty arbitrary.  Besides guessing that 0-10 or 0-15 
isn't quite enough granularity, I don't care if it is 0-255, or 0-65535.

Remember, the eye is a logarithmic device, so you have quite a few
decades of intensity to cover.  I'd pick either 0-255 or 0-65535, rather
than 0-15.

				- Jim

--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg...@pa...

RE: [Linux-fbdev-devel] Re: Framebuffer API with backlit displays

[Christian, A. <And...@co...>]

Russ Dill has been working on a generic backlight interface - see his
patch at http://russ.dhs.org/files/tuxpatches/backlight-2.4.16-rmk1.
The interface ioctl's include current and maximum backlight values. =20

I'd also add to the blanking and back/frontlight control a "screen
dimming" option.  The new OLED display panels burn power proportional to
screen brightness.

	- Andrew

> -----Original Message-----
> From: James Simmons [mailto:jsi...@tr...]
> Sent: Monday, December 17, 2001 5:27 PM
> To: Gettys, James
> Cc: Geert Uytterhoeven; Christian, Andrew; Packard, Keith; Linux Frame
> Buffer Device Development
> Subject: Re: [Linux-fbdev-devel] Re: Framebuffer API with backlit
displays
>=20
>=20
> On Mon, 17 Dec 2001, Jim Gettys wrote:
>=20
> > The issue is that we really may need a new interface to control the
> > backlight/frontlight, rather than relying on the VESA levels for
> > control.
>=20
> > So trying to cram this into the exisiting interface is causing real
> problems,
> > and I think it is time for a new additional interface to control
> frontlight
> > backlight, rather than try to bandaid things as we have to date.
>=20
> I agree. We still need to keep the old blank ioctl but I really like
to
> see the creation of a real power management API. Screen blanking and
> back/fton lights control fulls under that category in my mind. Any
ideas
> for a API?
>=20
>   .-.                               .-.
>   oo|  Give Microsoft The Bird!!!!  oo|
>  /`'\  Use Linux!!!                /`'\
> (_;/)                            (_;/)
> -----------------------------------------------------
>=20

Re: [Linux-fbdev-devel] Re: Framebuffer API with backlit displays

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

On Mon, 17 Dec 2001, Jim Gettys wrote:
> The current VESA interface is sufficient for screen blanking, and X fully
> implements it.
> 
> For frontlight/backlight control, we need something like:
> 
> o query current brightness
> o set new brightness, and return old brightness.
> 
> What we implemented on the iPAQ was brightness between 0-99; 0 can
> be completely off, 99 maximum.
> 
> The iPAQ hardware itself actually has a different scale, but hardware
> dependent, so we scaled in our driver proportionately.
> 
> That's about all that is needed....

PowerMacs currently use 0-15 (cfr. include/asm-ppc/backlight.h).

What about extending the range to 0-255? Or should we go for 0-65535, cfr. CLUT
entries?

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] Re: Framebuffer API with backlit displays

[<jg...@pa...>]

The current VESA interface is sufficient for screen blanking, and X fully=

implements it.

For frontlight/backlight control, we need something like:

o query current brightness
o set new brightness, and return old brightness.

What we implemented on the iPAQ was brightness between 0-99; 0 can
be completely off, 99 maximum.

The iPAQ hardware itself actually has a different scale, but hardware
dependent, so we scaled in our driver proportionately.

That's about all that is needed....
                              - Jim


--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg...@pa...

[Linux-fbdev-devel] [PATCH] new fbdev api

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

Here is my patch for the new fbdev api coming up. It already has recieved
Geert's blessing. Please apply to 2.5.1. Thank you.

  .-.                               .-.
  oo|  Give Microsoft The Bird!!!!  oo|
 /`'\  Use Linux!!!                /`'\
(_;/)                            (_;/)
-----------------------------------------------------

--- linux-2.5.1/include/linux/fb.h	Wed Nov 28 16:43:10 2001
+++ linux/include/linux/fb.h	Thu Nov 29 11:02:26 2001
@@ -241,6 +241,39 @@
 	__u32 reserved[4];		/* reserved for future compatibility */
 };
 
+/* Internal HW accel */
+#define ROP_COPY 0
+#define ROP_XOR  1
+
+struct fb_copyarea {
+	__u32 sx;	/* screen-relative */
+	__u32 sy;
+	__u32 width;
+	__u32 height;
+	__u32 dx;
+	__u32 dy;
+};
+
+struct fb_fillrect {
+	__u32 dx;	/* screen-relative */
+	__u32 dy;
+	__u32 width;
+	__u32 height;
+	__u32 color;
+	__u32 rop;
+};
+
+struct fb_image {
+	__u32 width;	/* Size of image */
+	__u32 height;
+	__u16 dx;	/* Where to place image */
+	__u16 dy;
+	__u32 fg_color;	/* Only used when a mono bitmap */
+	__u32 bg_color;
+	__u8  depth;	/* Dpeth of the image */
+	char  *data;	/* Pointer to image data */
+};
+
 #ifdef __KERNEL__
 
 #if 1 /* to go away in 2.5.0 */
@@ -250,10 +283,10 @@
 #endif
 
 #include <linux/fs.h>
+#include <linux/poll.h>
 #include <linux/init.h>
 #include <linux/devfs_fs_kernel.h>
 
-
 struct fb_info;
 struct fb_info_gen;
 struct vm_area_struct;
@@ -283,9 +316,25 @@
     /* set colormap */
     int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, int con,
 		       struct fb_info *info);
-    /* pan display (optional) */
-    int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
-			  struct fb_info *info);
+    /* checks var and creates a par based on it */
+    int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);
+    /* set the video mode according to par */
+    int (*fb_set_par)(struct fb_info *info);
+    /* set color register */
+    int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
+                        unsigned blue, unsigned transp, struct fb_info *info);
+    /* blank display */
+    int (*fb_blank)(int blank, struct fb_info *info);
+    /* pan display */
+    int (*fb_pan_display)(struct fb_var_screeninfo *var, int con, struct fb_info *info);
+    /* draws a rectangle */
+    void (*fb_fillrect)(struct fb_info *p, struct fb_fillrect *rect); 
+    /* Copy data from area to another */
+    void (*fb_copyarea)(struct fb_info *p, struct fb_copyarea *region); 
+    /* Draws a image to the display */
+    void (*fb_imageblit)(struct fb_info *p, struct fb_image *image);
+    /* perform polling on fb device */
+    int (*fb_poll)(struct fb_info *info, poll_table *wait);
     /* perform fb specific ioctl (optional) */
     int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
 		    unsigned long arg, int con, struct fb_info *info);
@@ -309,6 +358,7 @@
    char *screen_base;                   /* Virtual address */
    struct display *disp;		/* initial display variable */
    struct vc_data *display_fg;		/* Console visible on this display */
+   int currcon;				/* Current VC. */	
    char fontname[40];			/* default font name */
    devfs_handle_t devfs_handle;         /* Devfs handle for new name         */
    devfs_handle_t devfs_lhandle;        /* Devfs handle for compat. symlink  */
@@ -387,6 +437,9 @@
 			  struct fb_info *info);
 extern int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
 			     struct fb_info *info);
+extern void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect); 
+extern void cfb_copyarea(struct fb_info *p, struct fb_copyarea *region); 
+extern void cfb_imageblit(struct fb_info *p, struct fb_image *image);
 
     /*
      *  Helper functions
@@ -400,6 +453,7 @@
 extern int fbgen_switch(int con, struct fb_info *info);
 extern void fbgen_blank(int blank, struct fb_info *info);
 
+extern void fbgen2_set_disp(int con, struct fb_info *info);
 
 /* drivers/video/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);

Re: [Linux-fbdev-devel] Re: Framebuffer API with backlit displays

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

On Mon, 17 Dec 2001, Jim Gettys wrote:

> The issue is that we really may need a new interface to control the
> backlight/frontlight, rather than relying on the VESA levels for
> control.

> So trying to cram this into the exisiting interface is causing real problems,
> and I think it is time for a new additional interface to control frontlight
> backlight, rather than try to bandaid things as we have to date.

I agree. We still need to keep the old blank ioctl but I really like to
see the creation of a real power management API. Screen blanking and
back/fton lights control fulls under that category in my mind. Any ideas
for a API?

  .-.                               .-.
  oo|  Give Microsoft The Bird!!!!  oo|
 /`'\  Use Linux!!!                /`'\
(_;/)                            (_;/)
-----------------------------------------------------

RE: [Linux-fbdev-devel] Network transparent API Concept Design

[Sottek, M. J <mat...@in...>]

>>Sorry for the delay. Finally I found time to read the document
>>and write my comments...

>> struct fb_display_info {
>>    u32 id;
>>    u32 xres;
>>    u32 yres;

>Are these visible xres and yres?

"Display" is ONLY visible. The biggest design feature was the separation
of "Display Timings" from "Mode". Display is what you are outputting
to a display device. Mode is what you are rendering. So yes this is
visible only.

>Are these the sync margins? What about hsync_len and vsync_len?

No. The user should forget they ever knew anything about syncs and
such. They are for the driver to decide. These margins _may_ be
translated into sync fudging to move the picture on a CRT, but that
would be bad. Most hardware vendors have a fixed set of timings and
don't shift them around. Monitor vendors don't like you messing with
the syncs either. Calculate them according to the VESA guidelines
and leave it at that.
What this may be good for is the new DDC that allows altering of the
monitor positioning. Or on a "virtual" display of some type it could
move the data within a larger image, or if the image is "centered"
on a digital display this could alter the position.

The point is that the user doesn't care. If the driver can let you move
the picture around on the screen it will do so. Otherwise nothing
happens.

> struct fb_mode_info {
>    u32 width;
>    u32 height;

>Are these virtual width and height?
Yes, but don't think of it that way. It is the resolution that you are
rendering. So if you hardware is creating 1024x768 images but your
display is only showing 8x6 then yes this is the same as "virtual"
resolution.

"Virtual" resolution is really used when it shouldn't be. It should
mean a resolution bigger than what is being rendered. Like multiple
desktops in X. Data that doesn't really exist in a physical manner
all the time == virtual. There is nothing virtual about a plain 10x7
framebuffer... even when your display is only showing 8x6.  But I
digress, everyone uses virtual to mean "Bigger than your display" so
there is no changing it now :)

>There exist many different variants of YUV: 4:4:4, 4:2:2, 4:2:0,
>Depending on the hardware, YUV modes can be interlaced and/or
>interleaved. E.g. some Set Top Box S(TB) hardware splits the YUV
>data in four parts: Y even, Y odd, UV even, and UV odd.

>What about RGBA?

>Are these all packed? What about planar modes and interleaved
>planes?

>So Amiga HAM6 and HAM8 can be considered NONSTD.

>What about weird endianness? E.g. RGB565 can look very weird
>(GGGBBBBBRRRRRGGG) if bytes have to be swapped, but not 16-bit words.

>On some architectures (e.g. ARM), video memory accesses must always
>be x-bit wide.

Ok all these fall into the same category. I made no attempt in the
design doc to cover all possible pixel formats. The concept was
that instead of trying to describe the pixels with offsets, depths,
etc. just use a 32 bit unique id. 2^32 is plenty of pixel formats to
cover whatever odd stuff we come across.

Now secondly. I realize that just numbering the pixel formats 0,1,2...
as we come across them isn't going to work. User apps would have tons
of code like this:

switch(pixel_format) {
case 0x12345678:
case 0x32123456:
case 0x23145634:
   do_something();
case 0x43245689:
   something();
}

So I provided some ideas about how to "group" the id's into bitfields
that would help out. So you can do something like this in user apps
if you wanted to support all RGB32 variants.

if((pixel_format & (RGB | 32BIT) == (RGB | 32BIT)) {
   format_info = rgb32_format_table[(pixel_format & ID_MASK)>>8];
}
red = (red<<format_info->red_shift) & format_info->red_mask;
 or some such thing

The benefits are that, given an good set of groupings, you are never
going to be unable to represent a new format. When you use depths,
offsets, masks etc. You are always going to be unable to represent some
types and you've wasted a bunch of driver space and time in the process.

Drivers can use id's very fast. They already know exactly what they
are going to support, and it is a small number. The driver shouldn't
have to decode the pixel formats from descriptions just to figure out
how to render a character. They should just do a simple switch with
the 4 or 5 formats they support.

>Don't you need bit field positions? Other fields than R, G, B, and A.

Not in the driver I don't. Each one is unique. If you have 10 different
RGBA32's then they all look the same except for the id bits. Look
the positions up in a table (in user-space).

>No XOR index (index of the color entry that inverts the
>underlying pixel)? Flashing cursors?

Yea, There are probably lots of odd cursor out there to account for.

>Perhaps hardware animation (some STBs have that)?

That can work. Just use a pixel format that has a bunch of images in
whatever format such a beast would need. This is probably done with
a bunch of similar cursor images stacked up in adjacent memory? Works
just fine.  Probably want to keep that "clever" pixel format as a
device private one.

>So different layers/planes are different surfaces. STBs can do
>different layers (a few YUV, a few RGB/CLUT for OSD, cursor),
>with alpha blending between the layers, changeable order, ...

Surfaces are a representation of memory regions that are useful to
user apps. Most likely you would have one for each "plane" but
they are just a way to access and get information about the memory.
You need to use another interface to "control" the surfaces.

i.e. The framebuffer is a surface. You use the set_mode() get_mode()
set_display() etc. To "control" the framebuffer. The surface just
tells you where the memory is, if it is dirty etc.
 For overlay's we need a set of interfaces to "control" the features.
I didn't make an attempt on those yet. We have bigger problems
to solve :)

  Note that you can do whatever you want with a surface. If it is a
driver private surface type you can have driver private ways of
controlling it. Overlays and such may be so complicated that we just
decide to export driver private interfaces and wrap them in user-space
with a library. No need to make the driver work harder than it must.

>This is for packed pixels only. For (interleaved) bitplanes you
>need an offset to the next line and next plane.

Not really. You have to take into account the pixel format. If the
format is such that you have interleaved data then you should know
"how" the data is interleaved. If it is planar data then you should
know where the next plane begins. For instance, a Planar YUV 4:2:0
format would be defined to have the U plane at width*height offset
into the surface, and it would have width == width/2. All
surfaces with the same pixel format have the same layout.
  Since this is of course a device file we are talking about, you
don't have to actually have the memory layout as described. The U
and V data could be somewhere else, but you just use the "defined"
area of the device file as the access point.

>Is the lseek() really needed? This means we need 2 syscalls
>(context switches) instead of 1.

This is _very_ open for comment. I just wanted to provide an example
to show people that using a command file doesn't mean writing ascii
into a file to be parsed by the kernel. Ascii is only good for human
interfaces. The interface between an application and the kernel has
no use for ascii.

I had assumed (In hindsight this assumption was complete garbage on
my part) that reading/writing to a device file worked over NFS as
long as you didn't do any "Device" type things (mmap, ioctl). This
isn't the case. Clearly it IS possible to make some type of filesystem
that has network capability of this fashion, perhaps devfs can
do this??
So I'm sure the way I described isn't the best. We just need to come
up with one that is easy on both ends. Removing the seek is an easy
first step.

>> KERNEL INTERFACE:
>No overlay console? ;-)

Actually I was thinking of attaching a kernel interface to a
surface so you could do something like that. I'm still thinking
about it.

>> fb_put(u8 *data, u16 srcx, u16 srcy, u16 width, u16 height, u16 
         ^^^^
>	 void *?

Sure, that is cleaner.

>BTW, on many STBs, the whole screen is not one pixmap, but you can
>have multiple non-overlapping regions (windows), using different
>pixel formats.

Well that requires some driver specific applications anyway right?
Just define the framebuffer as a driver private pixel format and
make each "region" have its own surface. Write to the surfaces and
never to the whole framebuffer surface.

-> copyrect
-> fillrect
-> imageblit

 If you want to keep all the character drawing at the di layer then
all the console functions can go away. Just use put() set() get()
copy().
 I haven't looked at imageblit yet. If it requires driver to support
pixel formats that are not native then it is totally unacceptable.
The kernel guys have said forever that sound format conversion doesn't
belong in the kernel. Image format conversion isn't any different.
If the hardware supports the conversion, then fine. Otherwise punt.

  I was thinking about Petr's comments on needing to be able to access
the hardware conversion capabilities. My put() and get() don't have
a format type... for the reasons above. I was thinking that I could
add a list of alternative formats to each surface. Then you could either
write to the surface in it's native format or in an alternative format
that the hardware can convert.

> fb_base: This is a kernel-virtual address that points to the 
                   ^^^^^^^^^^^^^^^^^^^^^^^^???
> beginning of the framebuffer. This address can be written to in 
> a manner such as this "*fb_base = 0;". Typically this is an 
> ioremapped version of the physical base address of the 
> framebuffer.

What is the problem here? Are you wondering about the terminology?
Virtual address == paged. kernel address == one for use in the kernel.
kernel virtual is a paged address for use in the kernel.
As opposed to physical or bus address which you need to remap. Or
a user address which is virtual but in a private address space for the
process.

 -Matt