Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <jsi...@tr...> - 2001-11-25 05:51:21
|
> No I wasn't talking about anything that complex. I just don't want > userland or anyone outside my driver using the pointers I am required > to provide. I'm just going to set them all to zero, and whatever falls > over needs to be fixed. Set the fb_fix fields for mmio and smem to zero. As for internally with the new api you don't need to use the screen_base field. Just ignore it. > It isn't like the > kernel gives you full access but will kill you if you do something > wrong, there is no interface to allow you to do something wrong in > the first place. > > I think the kgi does more of what you are talking about here. No KGI works just the way you described DRI does. KGI uses a metadata system to render graphics commands. Basically you can create data packets of what you want done and send it out. The kernel interpets the data and executes it safely. Well okay KGI takes it a step further than DRI. The method I described is the way IRIX handles it on SGI systems. |
|
From: James S. <jsi...@tr...> - 2001-11-25 05:42:57
|
> I agree that EDID needs to be supported, but the data structures could > be a slight superset of EDID. All the matters is that the information > isn't lost. EDID is certainly a good example of what needs to be > represented by whatever the final data structure is. Agree. I just want to make sure we can support platforms with their own vanilla thing. You just never know. > I also advocate the ability to populate the EDID data structure from > user-space, which _could_ include a specific set of timings. That was what fbmon.c was supposed to do. Never got around to it. Now that 2.5.X is here we can start banging away at it. > Why would I want to make a human readable interface? Because linus wants ioctls to go away in 2.5.X. > Most high end features are going to > remain device specific and should only be used via a userspace library. No doubt about that. I have only ever advocated resource management between processes, not programming hardware in the kernel. Hm. I don't know how Linus expects me to figure out a ASCII only interface to graphics hardware. Anyways that is way down the road. |
|
From: Paul M. <le...@Ch...> - 2001-11-25 05:40:35
|
On Sun, Nov 25, 2001 at 02:34:33AM +0100, Petr Vandrovec wrote: > Are you sure that this is really needed? You are not inventing API for ne= xt > 20 years. You are inventing API now, for current products. You can change > API anytime in future, and API will definitely change, as it already > changed in the past. Also EDID is so universal that you can express > almost everything using that, and also do not forget that there exist > bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and > that this bidirectional communication may be required for proper operation > (i.e. enabling) of USB/IEEE1394 ports built into monitor. > =20 VBE DDC is something else to consider as well.. > > /dev/gfx/card0/frame0/resolution > > /endian > > /frame > > =09 > > To change the resolution of a framebuffer we can do a=20 > >=20 > > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. =20 > >=20 > > As you can see with this new design we have alot more flexiablity. Lots= of > > other nice features but this is down the road. >=20 > Yes. For example floating point support in the kernel. I'd like to know= =20 > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be= =20 > NTSC 800x525 interlaced picture, and how you'll center picture on screen > then? Where do you specify virtual xres and yres? > =20 Your overthinking it. For one, as long as modes are in a consistent format, it's easy for anyone to parse. And since people are already used to the "640x480-16@70" style format, what's the big deal? As far as virtual xres and yres.. keep in mind this is a virtual filesystem= .. if your driver or subsystem has additional needs, you can simply register a new entry to deal with virtual resolution.. If you want a place for virtual resolution.. something like: /dev/gfx/card0/frame0/resolution_virt should suffice just fine. (Name pending). Regards, --=20 Paul Mundt <le...@ch...> |
|
From: James S. <jsi...@tr...> - 2001-11-25 05:30:46
|
> Are you sure that this is really needed? You are not inventing API for next > 20 years. You are inventing API now, for current products. You can change > API anytime in future, and API will definitely change, as it already > changed in the past. Also EDID is so universal that you can express > almost everything using that, and also do not forget that there exist > bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and > that this bidirectional communication may be required for proper operation > (i.e. enabling) of USB/IEEE1394 ports built into monitor. As pointed out their should exist a supset that EDID is apart of. I don't want to run into a issues of some platform using something else that works just as well. I like to think functionality. This kind of thinking will go further. > And our monitors will do plop and disappear? We are using 12 years old > monitors for some tasks, and we'll not throw them away before they'll > physically stop functioning. The reality is if you write the drivers correctly you can have drivers that do the timing for you. Yes you would have to supply the data for the monitor attached before. Their exist receipes for this. > Yes. For example floating point support in the kernel. I'd like to know > how you'll persuade driver to know that '640x480-YUV422@59.94i' should be > NTSC 800x525 interlaced picture, and how you'll center picture on screen > then? Where do you specify virtual xres and yres? Don't shot me. Linus has pointed out that ioctls are to go away in 2.5.X. > > Agree. This will change. Plus the gfx interface I mention above wil be my > > attempt to combine DRI and fbdev. > > There are drivers which support text modes - and if your new API will not > support them... well, you'll have to create another API. Wrong. You create another console driver. Take a look at the STI console code for the PARISC platform. A excellent example. Core code which has a fbdev driver on top for graphcis modes and a sticon for using a text mode from the ROM. Using fbdev for text modes is way to much overhead. Using struct consw only is much lighter in weight. The aim here is to remove bloat. Plus the console code will be removed from all low level drivers period. The embedded industry demands it. I know since I work in it. In the console project we have NVIDIA text console driver. For matrox you could have a matroxcon. Very simple and very sweet. > It is something else. You can have two CRTCs (== two /dev/fb*), four > outputs (analog VGA #1, analog VGA #2, digital FP #1 and TVOut #1) of > which 2 or 3 can be active at one time, and a scaler which can insert > third picture into one of outputs... API should at least provide > universal way for enumerating device outputs and finding dependencies > between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and > /dev/fb2 shares memory and outputs with /dev/fb3). The struct xxx_par represents the hardware state. This encompesses the entire board. So you would place everthing in there. struct fb_info represents one framebuffer and its properties. Thats all. Very simple and very clean. |
|
From: Matt S. <mat...@ho...> - 2001-11-25 04:58:36
|
>Are you sure that this is really needed? You are not inventing API >for next 20 years. You are inventing API now, for current products. >You can change API anytime in future, and API will definitely >change, as it already changed in the past. Also EDID is so >universal that you can express almost everything using that, and >also do not forget that there exist bidirectional channel >(DDC2B+/DDC2AB) between videocard and monitor, and that this >bidirectional communication may be required for proper operation >(i.e. enabling) of USB/IEEE1394 ports built into monitor. I agree that EDID needs to be supported, but the data structures could be a slight superset of EDID. All the matters is that the information isn't lost. EDID is certainly a good example of what needs to be represented by whatever the final data structure is. >> > * The user api needs to move away from timings all together. >> > The user should be able to select a refresh rate from a provided >> > list (negotiated between monitor and driver). It won't be long >> > before timings are no longer used in hardware, and the only thing >> > left to adjust will be refresh. >And our monitors will do plop and disappear? We are using 12 years old >monitors for some tasks, and we'll not throw them away before they'll >physically stop functioning. I wasn't saying that at all. I am just talking about the user visible api. User applications don't need to concern themselves with timings. The driver should be able to do the right thing with historical VESA timing sets, timing algorithms, and EDID like information. Timings should just be hidden from the user. I also advocate the ability to populate the EDID data structure from user-space, which _could_ include a specific set of timings. Think of this scenario. A Monitor with no EDID, the driver probably has to assume a standard VGA monitor that can do only 60hz at say 10x7. The user would have to have the ability to override the monitor specs and provide a timing range or specific timing sets. The driver, which should be giving priority to the timings from the Monitor, would then choose the user supplied timings. But, for the average case where the default timings are fine or the monitor provided EDID information. The whole thing "just works" without the user knowing anything more than the resolution depth and possibly refresh. >> /dev/gfx/card0/frame0/resolution >> /endian >> /frame >> > To change the resolution of a framebuffer we can do a >> > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. >> > As you can see with this new design we have alot more flexiablity. Lots of >> other nice features but this is down the road. >Yes. For example floating point support in the kernel. I'd like to know >how you'll persuade driver to know that '<EMAIL: PROTECTED>' should be >NTSC 800x525 interlaced picture, and how you'll center picture on >screen then? Where do you specify virtual xres and yres? I'm with Petr here. If this is the interface for mode setting you've got problems. Why would I want to make a human readable interface? So an application can convert the parameters it wants to ascii to pass them to the kernel who then parses and decodes an ascii command packet to get the data back? What benefit is this? Ascii interfaces are great for OUTPUT, and even then, only if the data is useful in a shell. I don't think the complex set of interactions that are involved in negotiating a set of timings and the framebuffer mode are a good fit for a single directional ascii interface. Plus this is a slippery slope, are you planning on using this type interface for cursor position? Certainly I would prefer an optimized ioctl path over a text based one for anything that happens on a regular basis. I can see having the gfx filesystem for things that can be done in a shell. cat /dev/gfx/something/fb > screenshot.tiff seems reasonable. cat /dev/gfx/something/mode is reasonable too, but only for human reading. No application should be required to parse the ascii output just to get the resolution/depth/acceleration information. If that were the case you'd have to make a library to do it, since surely all the fb applications wouldn't want to write their own parser... and if you were going to write a library why wouldn't you just use an ioctl which could do it without going kernel:data->kernel:ascii->user:ascii->user:data > API should at least provide >universal way for enumerating device outputs and finding dependencies >between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and >/dev/fb2 shares memory and outputs with /dev/fb3). You are correct, there is probably a clean interface to be had in the case I mentioned. I was simply observing that currently if any driver ever needed a variable of any kind it was stuffed in "fix" or "var" or "display" which are now all hopelessly full of garbage that is meaningless in 90% of the use cases for those structures. A reset is needed and this time don't make a set of bits or a well defined ioctl or a variable for every little feature. Most high end features are going to remain device specific and should only be used via a userspace library. Think openGL. you can't have all 3d apps calling directly down to a triangle function that is different for each set of hardware, and you can't make the kernel do the work to convert between a standard API and the hardware implementation. The solution is to just export a device specific API from the kernel and make the standard API (opengl) in userland. -Matt |
|
From: Petr V. <van...@vc...> - 2001-11-25 02:01:02
|
On Sat, Nov 24, 2001 at 08:52:09AM -0800, James Simmons wrote: > > something special that I can support. To aid in code reuse you > > should just provide a function that parses EDID data into an > > edid data structure (Something like this was discussed a few > > day ago) > > Most defintely. That was what fbmon.c was for. Unfortunely I never had the > time to work on it. Now that 2.5.0 is out I'm going to figure something > out. I did see the patch sent out and I'm going to start with that. I just > like to make monitor stuff EDID independent. I don't want to be stuck with > this api for the next 20 years especially when the technology will change. Are you sure that this is really needed? You are not inventing API for next 20 years. You are inventing API now, for current products. You can change API anytime in future, and API will definitely change, as it already changed in the past. Also EDID is so universal that you can express almost everything using that, and also do not forget that there exist bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and that this bidirectional communication may be required for proper operation (i.e. enabling) of USB/IEEE1394 ports built into monitor. > > * The user api needs to move away from timings all together. > > The user should be able to select a refresh rate from a provided > > list (negotiated between monitor and driver). It won't be long > > before timings are no longer used in hardware, and the only thing > > left to adjust will be refresh. And our monitors will do plop and disappear? We are using 12 years old monitors for some tasks, and we'll not throw them away before they'll physically stop functioning. > /dev/gfx/card0/frame0/resolution > /endian > /frame > > To change the resolution of a framebuffer we can do a > > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. > > As you can see with this new design we have alot more flexiablity. Lots of > other nice features but this is down the road. Yes. For example floating point support in the kernel. I'd like to know how you'll persuade driver to know that '640x480-YUV422@59.94i' should be NTSC 800x525 interlaced picture, and how you'll center picture on screen then? Where do you specify virtual xres and yres? > > graphics driver and isn't appealing as a base driver to expand > > on. > > Agree. This will change. Plus the gfx interface I mention above wil be my > attempt to combine DRI and fbdev. There are drivers which support text modes - and if your new API will not support them... well, you'll have to create another API. > > #3 Don't try to wrap everything in a hardware independent API. Some > > hardware is going to support things that others don't. Take for > > instance "mirroring". The i810 can do this on the CRT + a TV or > > FP depending on what is connected. But the modes that can be > > supported are very limited and mucking up a mode API with this > > This is what struct fb_info.par is for. It is the hardware dependent > structure in struct fb_info. If you have more than one frmaebuffer on the > graphics card then you have 2 struct fb_info that share the same par. Now > if one attempts to set the graphics mode that both can't support at the > same time since they share the same par they will know before hand. That > is what fb_check_var is for. It is something else. You can have two CRTCs (== two /dev/fb*), four outputs (analog VGA #1, analog VGA #2, digital FP #1 and TVOut #1) of which 2 or 3 can be active at one time, and a scaler which can insert third picture into one of outputs... API should at least provide universal way for enumerating device outputs and finding dependencies between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and /dev/fb2 shares memory and outputs with /dev/fb3). Best regards, Petr Vandrovec van...@vc... |
|
From: Matt S. <mat...@ho...> - 2001-11-25 01:04:02
|
> > No doubt, as you state, there are applications that would need the > > physical framebuffer address. The problem is that when you just leave > > a pointer laying around in a public data structure there is no way > > for a user application to know when the pointer is valid and when it > > is not. If a unsuspecting TV capture card tried to use my physical > > address without knowing that I only have 64k banks the whole system > > would come down hard. > > Ah. You are talking about having a real RRM (rendering resource manager). > When a process open /dev/fb or DRI it should be registered with the RRM. > Then when someone does something global like change the graphics > resolution the RRM sends a signal to all the processes that are using the > graphics card resources. As for the 64k bank sitution you can use VM > tricks to make it appeard linear to userland. If you something really > bizarre then you add something on the order of: > No I wasn't talking about anything that complex. I just don't want userland or anyone outside my driver using the pointers I am required to provide. I'm just going to set them all to zero, and whatever falls over needs to be fixed. > > MMio is a very different animal. Most mmio regions are not safe for > > untrusted userspace binaries to access. This is why such access is > > limited to root. Further there is no generic use for these mmio regions, > > only a userspace driver would know what to do with them. Certainly a > > userspace driver and kernelspace driver that are working together should > > be able to work out a way to share the locations they need without > > leaving them lay around in public. > > It doesn't have to be root. DRI allows normal clients to use the MMIO > regions. The key is that you have a RRM that is the guardian angel. If a > process does the naughty you kill it and reset the accel engine. > No it doesn't. The DRM only allows clients to map regions that are safe. This doesn't include the mmio registers for most cards. The drm provides safe interfaces to do dma and dispatch commands. It doesn't just let clients touch the registers. For instance on i810 you can map a dma buffer into the client but in order to dispatch a command the kernel unmaps the buffer from the client writes the instruction to the dma buffer and then dispatched the buffer. It isn't safe on i810 to allow the client full access even to the dma buffers. It isn't like the kernel gives you full access but will kill you if you do something wrong, there is no interface to allow you to do something wrong in the first place. I think the kgi does more of what you are talking about here. -Matt |
|
From: James S. <jsi...@tr...> - 2001-11-24 18:20:31
|
I broke the patche up into a few patches. Basically I have added a new
generic framebuffer system (fbgen2.c). To convert to this new gen layer
you need to do a few things.
1) Get ride of your
struct fb_info_xxx {
...excess junk ...
struct fb_info *info;
.. more excess junk...
}
Instead use a
struct xxx_par {
/* All driver specific data. */
}
statci struct xxx_par default_par;
struct fb_info info;
xxxfb_init()
{
....
info.par = default_par;
....
}
Trust me. This will make for a much cleaner more transparent system. I
have done several drivers this way. In this design par is only avaliable
to the local driver. The upper fbdev and fbcon code doesn't know about it.
2) New function pointers have been added into struct fb_ops. They are
int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info)
The above function validates a graphics resolution. It does NOT alter the
hardware state in xxx_par.
int (*fb_set_par)(struct fb_info *info);
This above function sets the hardware state according to the new var which
is placed into struct fb_info in the upper layers. So all you have to pass
into this function is info. Par which is always the current hardware state
so it is always in info.
int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
unsigned blue, unsigned transp, struct fb_info *info);
This is to kill the stupidity of passing around the function pointer to
setcolreg to fb_set_cmap. Since we use the cmap field in struct fb_info
this makes the need for fb_get_cmap go away :-). Also the info->palette
crap can finally go away.
Here is the patch and code to fbgen2.c. Please review it as I plan to send
it to Linus with Geert's blessing.
/*
* linux/drivers/video/fbgen2.c -- Generic routines for frame buffer devices
*
* Created 27 June 2001 by "Crazy" James Simmons <jsi...@tr...>
*
* 2001 - Documented with DocBook
* - Brad Douglas <br...@ne...>
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
* for more details.
*/
#include <linux/module.h>
#include <linux/string.h>
#include <linux/tty.h>
#include <linux/fb.h>
#include <linux/slab.h>
#include <asm/uaccess.h>
#include <asm/io.h>
#include <video/fbcon.h>
/**
* fbgen_set_disp - set generic display
* @con: virtual console number
* @info: generic frame buffer info structure
*
* Sets a display on virtual console @con for device @info.
*
*/
void fbgen2_set_disp(int con, struct fb_info *info)
{
struct display *display;
if (con >= 0)
display = &fb_display[con];
else
display = info->disp; /* used during initialization */
display->screen_base = info->screen_base;
display->var = info->var;
display->visual = info->fix.visual;
display->type = info->fix.type;
display->type_aux = info->fix.type_aux;
display->ypanstep = info->fix.ypanstep;
display->ywrapstep = info->fix.ywrapstep;
display->line_length = info->fix.line_length;
if (info->blank || info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR)
display->can_soft_blank = 1;
else
display->can_soft_blank = 0;
#if 0 /* FIXME: generic inverse is not supported yet */
display->inverse = (info->fix.visual==FB_VISUAL_MONO01 ? !inverse : inverse);
#else
display->inverse = info->fix.visual == FB_VISUAL_MONO01;
#endif
switch (info->var.bits_per_pixel) {
#ifdef FBCON_HAS_CFB4
case 4:
display->dispsw = &fbcon_cfb4;
break;
#endif
#ifdef FBCON_HAS_CFB8
case 8:
display->dispsw = &fbcon_cfb8;
break;
#endif
#ifdef FBCON_HAS_CFB16
case 12:
case 16:
display->dispsw = &fbcon_cfb16;
display->dispsw_data = info->pseudo_palette;
break;
#endif
#ifdef FBCON_HAS_CFB32
case 32:
display->dispsw = &fbcon_cfb32;
display->dispsw_data = info->pseudo_palette;
break;
#endif
default:
display->dispsw = &fbcon_dummy;
break;
}
}
/* ---- `Generic' versions of the frame buffer device operations ----------- */
/**
* fbgen_get_fix - get fixed part of display
* @fix: fb_fix_screeninfo structure
* @con: virtual console number
* @info: frame buffer info structure
*
* Get the fixed information part of the display and place it
* into @fix for virtual console @con on device @info.
*
* Returns negative errno on error, or zero on success.
*
*/
int fbgen_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info *info)
{
*fix = info->fix;
return 0;
}
/**
* fbgen_get_var - get user defined part of display
* @var: fb_var_screeninfo structure
* @con: virtual console number
* @info: frame buffer info structure
*
* Get the user defined part of the display and place it into @var
* for virtual console @con on device @info.
*
* Returns negative errno on error, or zero for success.
*
*/
int fbgen_get_var(struct fb_var_screeninfo *var, int con, struct fb_info *info)
{
if (con == info->currcon)
var = &info->var;
else
var = &fb_display[con].var;
return 0;
}
/**
* fbgen_set_var - set the user defined part of display
* @var: fb_var_screeninfo user defined part of the display
* @con: virtual console number
* @info: frame buffer info structure
*
* Set the user defined part of the display as dictated by @var
* for virtual console @con on device @info.
*
* Returns negative errno on error, or zero for success.
*
*/
int fbgen_set_var(struct fb_var_screeninfo *var, int con, struct fb_info *info)
{
struct fb_bitfield oldred, oldgreen, oldblue, oldalpha;
int oldbpp, err;
if (memcmp(&info->var, var, sizeof(var)) || con < 0) {
if ((err = info->fbops->fb_check_var(var, info)))
return err;
if (var->activate & FB_ACTIVATE_ALL)
info->disp->var = *var;
if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
oldbpp = info->var.bits_per_pixel;
oldred = info->var.red;
oldblue = info->var.blue;
oldgreen = info->var.green;
oldalpha = info->var.transp;
if (info->fbops->fb_set_par)
info->fbops->fb_set_par(info);
info->var = *var;
fbgen2_set_disp(con, info);
if (info->changevar)
(*info->changevar)(con);
if (oldbpp != var->bits_per_pixel ||
memcmp(&oldred,&info->var.red,sizeof(oldred)) ||
memcmp(&oldgreen,&info->var.green,sizeof(oldgreen)) ||
memcmp(&oldblue, &info->var.blue, sizeof(oldblue)) ||
memcmp(&oldalpha,&info->var.transp,sizeof(oldalpha))){
if ((err = fb_alloc_cmap(&info->cmap, 0, 0)))
return err;
fb_set_cmap(&info->cmap, 1,
info->fbops->fb_setcolreg, info);
}
}
var->activate = 0;
}
return 0;
}
/**
* fbgen_get_cmap - get the colormap
* @cmap: frame buffer colormap structure
* @kspc: boolean, 0 copy local, 1 put_user() function
* @con: virtual console number
* @info: frame buffer info structure
*
* Gets the colormap for virtual console @con and places it into
* @cmap for device @info.
*
* Returns negative errno on error, or zero for success.
*
*/
int fbgen_get_cmap(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info)
{
struct fb_cmap *dcmap;
if (con == info->currcon)
dcmap = &info->cmap;
else
dcmap = &fb_display[con].cmap;
fb_copy_cmap(dcmap, cmap, kspc ? 0 : 2);
return 0;
}
/**
* fbgen_set_cmap - set the colormap
* @cmap: frame buffer colormap structure
* @kspc: boolean, 0 copy local, 1 get_user() function
* @con: virtual console number
* @info: frame buffer info structure
*
* Sets the colormap @cmap for virtual console @con on
* device @info.
*
* Returns negative errno on error, or zero for success.
*
*/
int fbgen_set_cmap(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info)
{
struct fb_cmap *dcmap;
int err = 0;
if (con == info->currcon)
dcmap = &info->cmap;
else
dcmap = &fb_display[con].cmap;
/* no colormap allocated? */
if (!dcmap->len)
err = fb_alloc_cmap(dcmap, 256, 0);
if (!err && con == info->currcon)
err = fb_set_cmap(cmap, kspc, info->fbops->fb_setcolreg, info);
if (!err)
fb_copy_cmap(cmap, dcmap, kspc ? 0 : 1);
return err;
}
/**
* fbgen_update_var - update user defined part of display
* @con: virtual console number
* @info: frame buffer info structure
*
* Updates the user defined part of the display ('var'
* structure) on virtual console @con for device @info.
* This function is called by fbcon.c.
*
* Returns negative errno on error, or zero for success.
*
*/
int fbgen_update_var(int con, struct fb_info *info)
{
int err = 0;
if (info->fbops->fb_pan_display)
err = info->fbops->fb_pan_display(&fb_display[con].var,con,info);
return err;
}
/**
* fbgen_switch - switch to a different virtual console.
* @con: virtual console number
* @info: frame buffer info structure
*
* Switch to virtuall console @con on device @info.
*
* Returns zero.
*
*/
int fbgen_switch(int con, struct fb_info *info)
{
struct display *disp;
struct fb_cmap *cmap;
if (con == info->currcon)
return 0;
if (info->currcon >= 0) {
disp = fb_display + info->currcon;
/*
* Save the old colormap and video mode.
*/
disp->var = info->var;
if (disp->cmap.len)
fb_copy_cmap(&info->cmap, &disp->cmap, 0);
}
info->currcon = con;
disp = fb_display + con;
if (disp->cmap.len)
cmap = &disp->cmap;
else
cmap = fb_default_cmap(1 << disp->var.bits_per_pixel);
fb_copy_cmap(cmap, &info->cmap, 0);
info->var = disp->var;
info->var.activate = FB_ACTIVATE_NOW;
fbgen_set_var(&info->var, con, info);
return 0;
}
--- linux-2.5.0/include/linux/fb.h Fri Nov 23 23:01:48 2001
+++ linux/include/linux/fb.h Sat Nov 24 11:02:04 2001
@@ -283,6 +283,13 @@
/* set colormap */
int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, 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);
/* pan display (optional) */
int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
@@ -323,6 +330,7 @@
void *pseudo_palette; /* Fake palette of 16 colors and
the cursor's color for non
palette mode */
+ int currcon; /* Current console for fbdev */
/* From here on everything is device dependent */
void *par;
};
@@ -400,6 +408,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);
|
|
From: James S. <jsi...@tr...> - 2001-11-24 17:58:53
|
> > Tried it out. It didn't work for mach 64 card I have. It is really old. I > > have a 210888GX00 with a spectra DAC 2146886000. So it didn't detect it > > :-( > > That's normal. Support for Mach64GX is very limited due to the many choices of > external DACs and clockchips. You could add support for the spectra DAC, > though. I pan to. Especially since I want to port that driver over to the new api now that 2.5.X is out. |
|
From: James S. <jsi...@tr...> - 2001-11-24 17:42:03
|
> >Yes, that's what I did for atyfb (experimental 565 patch which doesn't work > >very well yet :-( > > Ok, well, it doesn't quite work yet but I suspect some X brokenness here. > > I'll got that fixed in both radeonfb and aty128fb this week-end hopefully. Can you pass along the fix to me. I recently rewrote the aty128fb driver for 2.5.X for the new api. I like to intergrate that fix into the driver. |
|
From: James S. <jsi...@tr...> - 2001-11-24 17:24:50
|
> DMA is not useable outside of the DRI anyway for now, or do you know of any > userland app doing this ? Nope. Do to the lack of docs on programming the api you haven't seen anything done. > I guess you need to have root access to the fbdev or something such to be able > to do dma, not sure though. No root!!! If the RRM is design right you don't need root. Well except for the master node (SGI terminology) that controls the global state. For example root would only change the resolution since this can affect every client using the accel engine. Even that I think doesn't have to be root. > Anyway, even X is not able to do DMA outside of the DRI setup. I would have > liked it when writing Xv support for the permedia3 chip. That sucks :-( |
|
From: James S. <jsi...@tr...> - 2001-11-24 17:21:14
|
> >> Currently mmio and fb pointers are in a PUBLIC data structure, a data > >> structure that is defined for everyone using the fb interfaces, both > >> kernel side and user side. > > >That is so you can do things like use the physical memory address of > >the framebuffer to display a image from a TV card into it. > > No doubt, as you state, there are applications that would need the > physical framebuffer address. The problem is that when you just leave > a pointer laying around in a public data structure there is no way > for a user application to know when the pointer is valid and when it > is not. If a unsuspecting TV capture card tried to use my physical > address without knowing that I only have 64k banks the whole system > would come down hard. Ah. You are talking about having a real RRM (rendering resource manager). When a process open /dev/fb or DRI it should be registered with the RRM. Then when someone does something global like change the graphics resolution the RRM sends a signal to all the processes that are using the graphics card resources. As for the 64k bank sitution you can use VM tricks to make it appeard linear to userland. If you something really bizarre then you add something on the order of: #define FB_AUX_TEXT_MDA 0 /* Monochrome text */ #define FB_AUX_TEXT_CGA 1 /* CGA/EGA/VGA Color text */ #define FB_AUX_TEXT_S3_MMIO 2 /* S3 MMIO fasttext */ #define FB_AUX_TEXT_MGA_STEP16 3 /* MGA Millenium I: text, attr, 14 This tells userland youhave something weird so watch out. > memory of some type for dma command buffers. Most chips cannot safely > give you full access to such memory areas. The sysmem_start and > sysmem_length seem to cover the whole graphics region, not just the > visible framebuffer. This is likely not safe. Then the driver is broken. This wouldn't be a first :-( > Mmap IS a driver interface. I can do all kind of tricks in the driver to > make sure a user who mmaps the framebuffer only gets access to what they > are supposed to. In my stolen memory driver I have zero-page fault > handlers to map and unmap regions while changing memory banks on the > fly. Nice tricks. > I can't do this when the kernel dereferences a kernel-virtual > address as is done in the logo code. There is no page fault handler for > me to catch. Don't worry this will go away in 2.5.X. The virtual poniter will remain for cards that need it, lacking any kind of acceleration. Since most cards are acclerated, even most embedded chips, the virtual pointer becomes optional. That is the key point. It is optional. That pointer then is only accessed in the software emulated accel functions that are needed. > MMio is a very different animal. Most mmio regions are not safe for > untrusted userspace binaries to access. This is why such access is > limited to root. Further there is no generic use for these mmio regions, > only a userspace driver would know what to do with them. Certainly a > userspace driver and kernelspace driver that are working together should > be able to work out a way to share the locations they need without > leaving them lay around in public. It doesn't have to be root. DRI allows normal clients to use the MMIO regions. The key is that you have a RRM that is the guardian angel. If a process does the naughty you kill it and reset the accel engine. > I would really like to get as many people looking at the whole fb > interface with a very critical eye. 2.5.x is the best opportunity we > will have to make drastic changes. We will have a very long time > before 3.0.0(?) to get things in shape. I don't want to settle for > half-done redesign when we could really make a good solid base to > build on for the next several years. I have been working on the fbdev api since janurary 1999. Part of it went in but unfortunely the TTY/console system lacked the power to allow the rest in. Now I have rewritten the console system to handle it. In the process I have realized how I could write wrapper until the TTY/console system gets cleaned up by me. |
|
From: James S. <jsi...@tr...> - 2001-11-24 16:52:14
|
> #1 Monitor timings/ mode setting is quite poor in 2.4.x. I haven't > looked at what you have so far but here are some points that > should be considered. > * Monitor timings are something that should be determined between > the driver and the monitor. Users and higher level api's should > not have anything to do with this. The driver I am working on > now has a fixed set of timings that it supports. When set_var > requests a new mode the closest match is found. It is key to > let the driver have it's own mode table. I also will eventually > parse EDID to add modes to my tables is the monitor needs > something special that I can support. To aid in code reuse you > should just provide a function that parses EDID data into an > edid data structure (Something like this was discussed a few > day ago) Most defintely. That was what fbmon.c was for. Unfortunely I never had the time to work on it. Now that 2.5.0 is out I'm going to figure something out. I did see the patch sent out and I'm going to start with that. I just like to make monitor stuff EDID independent. I don't want to be stuck with this api for the next 20 years especially when the technology will change. > * The user api needs to move away from timings all together. > The user should be able to select a refresh rate from a provided > list (negotiated between monitor and driver). It won't be long > before timings are no longer used in hardware, and the only thing > left to adjust will be refresh. > > #2 Complete separation of data structures. The var and fix structures > need rework badly. All things that are not explicitly needed by > a higher level api should not be in there. Those things belong > in the driver private data structures (It doesn't matter that > nearly everyone will have an mmio pointer, it doesn't belong in > a public data structure) First I plan to cleanup the framebuffer layer. Then with the new device filesystems coming up in 2.5.X plan to create a new interface for all this. So the current inteface will go away. I plan to make something like /dev/gfx/card0/frame0/resolution /endian /frame To change the resolution of a framebuffer we can do a cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution. As you can see with this new design we have alot more flexiablity. Lots of other nice features but this is down the road. > * The software fallback functions should be set up in a more > explicit way to keep these pointers out of other people's hands. > For example, the console functions (putc, putcs etc) should > be done something like this. > fb->console_ops = create_generic_console_ops(base,pitch,depth); > or use a hardware specific set as you would today. Those will be hidden from the fbdev driver writer. Then will all be managed in fbcon.c. > * I've seen mention of this in some posts but clearly the fb > driver should not be tied in any way to the console. My driver > has all the hardware functions totally independent of the > interface. The fbcon is an interface provided on top of a > graphics driver. They are currently way too connected, and > in my opinion this is one reason that a lot of the X & DRI > developers are not interested in combining efforts. The > result of console + graphics driver looks nothing like a > graphics driver and isn't appealing as a base driver to expand > on. Agree. This will change. Plus the gfx interface I mention above wil be my attempt to combine DRI and fbdev. > #3 Don't try to wrap everything in a hardware independent API. Some > hardware is going to support things that others don't. Take for > instance "mirroring". The i810 can do this on the CRT + a TV or > FP depending on what is connected. But the modes that can be > supported are very limited and mucking up a mode API with this > type of thing only makes a mess for everyone. Better to allow > a hardware specific switch to alter the output device and just > allow the driver to limit the available modes based on this > hardware specific switch. This is what struct fb_info.par is for. It is the hardware dependent structure in struct fb_info. If you have more than one frmaebuffer on the graphics card then you have 2 struct fb_info that share the same par. Now if one attempts to set the graphics mode that both can't support at the same time since they share the same par they will know before hand. That is what fb_check_var is for. > #4 It would certainly be nice to combine the drm code into the fb > code. NOTE: I wouldn't want to do this until the drivers are > organized like graphics drivers instead of consoles. Agree. |
|
From: Michel <mic...@ii...> - 2001-11-24 16:46:52
|
On Sat, 2001-11-24 at 13:11, Benjamin Herrenschmidt wrote: > >On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: > >> >Except that you can't change gamma, or am I on the wrong track here? > >>=20 > >> Well, X fbdev driver can only do truecolor afaik. It does send a > >> linear gamma table to the driver which is required anyway as the > >> fbdev themselves can be directcolor, but for real directcolor > >> support in X, we would probably need some other changes. > > > >So why does xgamma work with it? >=20 > I don't know ;) I've looked at the source and it clearly states > supporting only truecolor, but well, maybe xgamma is taking some > weird path within the X server ? No, it uses the very general path of calling the driver's LoadPalette() function, fbdevHWLoadPalette() in this case, which uses FBIOPUTCMAP ioctl. The comment apparently only applies to X visuals, I must confess I don't really know the difference there either. :) > BTW, I found my bug and now have 5:6:5 working properly. I'll > implement 5:5:5 and backport some of my fixes to aty128fb as > in it's current state, I beleive it's gamma setting doesn't > work properly neither. You get a clear picture because of the > hack that force a linear ramp when setting LUT entry 0, but > that hack can be removed if the rest is done properly ;) So directcolor works correctly now? Great! --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Benjamin H. <be...@ke...> - 2001-11-24 12:12:16
|
>On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: >> >Except that you can't change gamma, or am I on the wrong track here? >> >> Well, X fbdev driver can only do truecolor afaik. It does send a >> linear gamma table to the driver which is required anyway as the >> fbdev themselves can be directcolor, but for real directcolor >> support in X, we would probably need some other changes. > >So why does xgamma work with it? I don't know ;) I've looked at the source and it clearly states supporting only truecolor, but well, maybe xgamma is taking some weird path within the X server ? really no idea. BTW, I found my bug and now have 5:6:5 working properly. I'll implement 5:5:5 and backport some of my fixes to aty128fb as in it's current state, I beleive it's gamma setting doesn't work properly neither. You get a clear picture because of the hack that force a linear ramp when setting LUT entry 0, but that hack can be removed if the rest is done properly ;) Ben. |
|
From: James S. <jsi...@tr...> - 2001-11-24 07:34:04
|
Hi folks!!! As some might know I have been working for the last year in my spare time on the linux console project. Well it ended up as a total rewrite of the tty/console layer. In the new design the the tty/console layer is composed of seperate subsystems which can exist independently outside of the tty layer. Thus the tty layer is constructed from these subsystems. This makes for a cleaner mor emodular design. Some of things done are: 1) New framebuffer api. This new api allows the fbramebuffer layer to exist without a framebuffer console. This makes for a much simpler api and much smaller code. Plus on embedded devices like a iPAQ have a VT console doesn't make sense. Okay a stowaway does change that. But it would be nice if the VT system was modular and loadable :-) This is what we are working at. Pretty much complete. 2) Moving all the keyboards and other input devices over to the input api. Also makes for a nice modular design. Alot of work done. 3) Rewrite of the serial layer to be more like the parport layer. Here we have a hardware layer that registers ports and then we bind device interface drivers to specific ports. It makes no sense to use a serial tty to talk to a serial joystick for example. Plus their is a extra cost of going threw needless layers. This is partially complete but needs alot fo work. So expect patches. I also look forward to working with people to port devices over to these new APIs. Thank you. |
|
From: Michel <mic...@ii...> - 2001-11-24 02:42:24
|
On Fri, 2001-11-23 at 22:09, Petr Vandrovec wrote: > On 23 Nov 01 at 20:33, Michel D=E4nzer wrote: >=20 > > On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote: > > >=20 > > > > >Except that you can't change gamma, or am I on the wrong track her= e? > > >=20 > > > No. But it is much better to provide _global_ gamma correction settin= g, > > > so you can then apply this gamma table even to 8bit palettized mode, > > > and even without app knowledge. > >=20 > > That would require a new API, no? >=20 > Yes. > =20 > > Right now, apps use the colormap for this, and I'd hate to prevent them > > from doing so just because it's hard to get right. >=20 > There is no gamma API now. There is just an API to set RAMDAC, which > can be used as gamma in directcolor mode. But just in directcolor, > you cannot use it in palettized modes, although it is possible (as > in palettized mode RAMDAC is used in completely different way and it > cannot be used itself as gamma correction ramp), and also consoles will=20 > not use this gamma - only X can do (if they do...). We do, for both directcolor and pseudocolor. :) --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Carl P. <ca...@ed...> - 2001-11-23 20:20:14
|
I've got a Rage128 All-In-Wonder AGP. I'd like to use the TV out function of the card with FrameBuffer, but I cannot seem to find the correct video string to do it. I have tried: video=3Daty128fb:640x480 video=3Daty128fb:640x480-24@60 video=3Daty128fb:640x480-16@60 video=3Dvesafb:640x480 video=3Dvesafb:640x480-24@60 video=3Dvesafb:640x480-16@60 video=3Daty128fb:800x600 video=3Daty128fb:800x600-24@60 video=3Daty128fb:800x600-16@60 video=3Dvesafb:800x600 video=3Dvesafb:800x600-24@60 video=3Dvesafb:800x600-16@60 All of these produce a blank monitor and a blank TV. If I remove the TV connector and reboot, the monitor comes up fine. Running SuSE 7.3 with a 2.4.14 kernel. BIOS, and graphical LILO show up fine on both TV and monitor. When the FB driver is loaded I loose picture. Any ideas?? P.S. - Using composite TV out to a NTSC TV. Can use S-Vid once I get a cable today. --=20 -Carl Perry ca...@ed... "Deliver yesterday, code today, think tomorrow." -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/IT/>M d s++:- !a C++++ UL+++(++++)/V++++=20 P++ L++++ E- W+ N++ o K++++ w--- O M+ V-=20 PS+>++ PE- Y++>+++ PGP>+++ t+ 5+ X+ R tv b+>++ DI+++ D+ G>++ e>++ h !r y?=20 ------END GEEK CODE BLOCK------ |
|
From: Petr V. <VAN...@vc...> - 2001-11-23 20:10:00
|
On 23 Nov 01 at 20:33, Michel D=E4nzer wrote:
> On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote:
> > On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote:
> >
> > > >Except that you can't change gamma, or am I on the wrong track here=
?
> >
> > No. But it is much better to provide _global_ gamma correction setting=
,
> > so you can then apply this gamma table even to 8bit palettized mode,
> > and even without app knowledge.
>
> That would require a new API, no?
Yes.
> Right now, apps use the colormap for this, and I'd hate to prevent them
> from doing so just because it's hard to get right.
There is no gamma API now. There is just an API to set RAMDAC, which
can be used as gamma in directcolor mode. But just in directcolor,
you cannot use it in palettized modes, although it is possible (as
in palettized mode RAMDAC is used in completely different way and it
cannot be used itself as gamma correction ramp), and also consoles will
not use this gamma - only X can do (if they do...). As I'm using X just
only for VMware, gamma on consoles is much more important to me.
Petr Vandrovec
van...@vc...
|
|
From: Michel <mic...@ii...> - 2001-11-23 19:33:22
|
On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote: > On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote: >=20 > > >Except that you can't change gamma, or am I on the wrong track here? >=20 > No. But it is much better to provide _global_ gamma correction setting, > so you can then apply this gamma table even to 8bit palettized mode, > and even without app knowledge. That would require a new API, no? Right now, apps use the colormap for this, and I'd hate to prevent them from doing so just because it's hard to get right. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Michel <mic...@ii...> - 2001-11-23 18:59:28
|
On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: > >Except that you can't change gamma, or am I on the wrong track here? >=20 > Well, X fbdev driver can only do truecolor afaik. It does send a > linear gamma table to the driver which is required anyway as the > fbdev themselves can be directcolor, but for real directcolor > support in X, we would probably need some other changes. So why does xgamma work with it? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Petr V. <VAN...@vc...> - 2001-11-23 18:36:30
|
On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote:
> >Except that you can't change gamma, or am I on the wrong track here?
No. But it is much better to provide _global_ gamma correction setting,
so you can then apply this gamma table even to 8bit palettized mode,
and even without app knowledge.
> So for 5:6:5, doing only truecolor (and hard coding a linear ramp
> in the chip's LUT) would do the trick for now. MOL can use gamma too
> but it doesn't do 5:6:5, so it's a non-issue.
Petr
|
|
From: Benjamin H. <be...@ke...> - 2001-11-23 15:34:44
|
>Except that you can't change gamma, or am I on the wrong track here? Well, X fbdev driver can only do truecolor afaik. It does send a linear gamma table to the driver which is required anyway as the fbdev themselves can be directcolor, but for real directcolor support in X, we would probably need some other changes. So for 5:6:5, doing only truecolor (and hard coding a linear ramp in the chip's LUT) would do the trick for now. MOL can use gamma too but it doesn't do 5:6:5, so it's a non-issue. Ben. |
|
From: Michel <mic...@ii...> - 2001-11-23 14:56:17
|
On Fri, 2001-11-23 at 16:34, Petr Vandrovec wrote: > On 23 Nov 01 at 14:44, Benjamin Herrenschmidt wrote: > > >> cmap for regno 32..63, we should ignore R and B and only use > > >> G, or did I miss something ? > > > > > >Yes, that's what I did for atyfb (experimental 565 patch which doesn't= work > > >very well yet :-( > >=20 > > Ok, well, it doesn't quite work yet but I suspect some X brokenness her= e. > > I'll got that fixed in both radeonfb and aty128fb this week-end hopeful= ly. >=20 > Export truecolor (with RAMDAC hardwired to 1:1) and be happy... X works > very well in that mode, Except that you can't change gamma, or am I on the wrong track here? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Petr V. <VAN...@vc...> - 2001-11-23 14:35:06
|
On 23 Nov 01 at 14:44, Benjamin Herrenschmidt wrote:
> >> cmap for regno 32..63, we should ignore R and B and only use
> >> G, or did I miss something ?
> >
> >Yes, that's what I did for atyfb (experimental 565 patch which doesn't work
> >very well yet :-(
>
> Ok, well, it doesn't quite work yet but I suspect some X brokenness here.
> I'll got that fixed in both radeonfb and aty128fb this week-end hopefully.
Export truecolor (with RAMDAC hardwired to 1:1) and be happy... X works
very well in that mode, and setcolreg does not have to program each
RAMDAC register twice even if you reprogram complete palette.
Petr Vandrovec
van...@vc...
|
754 messages has been excluded from this view by a project administrator.
