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: Till A. <ti...@ad...> - 2001-11-17 11:37:09
|
Hello folks,
I've been trying to get the atyfb driver to work on my laptop which
sports a card that identifies itself as a ATI Mach64 : ATI|3D Rage LT
Pro AGP-133. I can select atyfb at boot time and pass it a resolution and
it boots up without complaint. The thing is, there isnt a single
resolution/depth combination that works as expected. Some
resolution/depth combinations produce only a flickering screen, some are
readable, but are missing about 1/3 of the right part of the screen,
some appear fine, but only cover an area in the upper left corner of the
screen and dont fill the screen.
Now this card supports something ATI calls ratiometric expansion, which
blows the screen up to the full size of the display. The laptop has a
key combination (Fn-F3) which toggles it. Booting the machine with
expansion off produces much better results than with it enabled,
although the screen does not get expanded (as is to be expected).
Hitting the above-mentioned key combination during operation causes a
hard lock of the machine.
If I'm reading the docs correctly, this feature is controllable via a
bunch of registers, that the atyfb does not apper to touch at all at the
moment. (Bear with me if I'm totally off here, I am no expert at any of
this by a long stretch). The mach64 driver included in the current
XFree86 on the other hand performs some initial setting up and later
disabling of this scaling feature, and the X driver performs beautifully
on this laptop.
So does the atyfb driver need to be extended to set the stretching
registers to a sane state to work properly with this card? If so, is
there someone on this list for whom this would be a three minute job and
who'd be willing to hack this in? I'm willing to help and test, but I'd
appreciate the guidance of someone with more experience in this.
I also noticed that the vertical yres is weird when using atyfb. I found
this around line 950 of atyfb_base.c which I dont understand and which I
think causes this:
if (var.yres == var.yres_virtual) {
32 vram = (fb->total_vram - (PAGE_SIZE << 2));
var.yres_virtual = ((vram * 8) / var.bits_per_pixel) / var.xres_virtual;
if (var.yres_virtual < var.yres)
var.yres_virtual = var.yres;
}
What is the reasoning behind this?
Cheers,
Till
--
mailto: ti...@ad...
http://www.adam-lilienthal.de/till
|
|
From: Sottek, M. J <mat...@in...> - 2001-11-17 00:28:38
|
>So what I need is the latest drivers from people so they can be
>ported over. I also want to>know what people needed for the fbdev
>layer as well as the input layer. I see some email about DDC
>support for example. Please let me know what you need. Thank you.
James,
Sorry to get such a late jump on giving input, but we can only
assume to have plenty of time before 2.6.x. Here is some input.
#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)
* 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)
* 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.
* 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.
#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. In MS this is like the display
properties dialog. The advanced options are dialogs written
specific for the hardware. We could just have a set of guidelines
for altering hardware specific configurations so that a command
line utility or GUI could be made to control them.
#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. There is
too much overlap now and it would just make for a really large
mess. Most of the dri enabled X drivers already have a different
code path for driver init than without dri so making the X servers
use fb+dri wouldn't be a such an issue. The main goal here would
be to eventually have a graphics driver setup that is easy to
configure. 1 kernel driver + 1 X driver == success. not 1 vga
driver + 1 fbcon driver + 1 drm driver + 1 X driver.
This is enough for discussion now,
-Matt
|
|
From: Sottek, M. J <mat...@in...> - 2001-11-17 00:16:06
|
I've been working on a sane i810 framebuffer that makes use of the chipset in the manner that it was designed to be used. This turns out to be very hard to work into the existing 2.4.x framebuffer API due to lots of assumptions and generic code not being very well suited to my needs. My basic issues surround the mixing of driver private information (memory pointers, mmio regions and other stuff that should NEVER be touched outside the driver) with information that gets leaked outside the driver, and even into user space. On i810 there is a region (512k or 1MB) that is stolen from the top of memory by the bios before the OS gains control. This memory is used, via hardware remapping of 0xa0000 and memory paging, for vga compatibility and for video drivers that do not use AGP services. In order to make the framebuffer play nicely with the DRM and X server I am making a framebuffer driver that, by default, only uses this stolen memory. The X server and framebuffer will then never have problems with ringbuffer corruption, Gart resource sharing etc. Now to the problem. I do not have a physical memory region that can be accessed linearly for the entire contents of the framebuffer. Not an issue provided that no one outside the driver tries to access the memory pointers (I was concerned from the beginning when I was asked to provide pointers to data structures that shouldn't have them). I wrote my own character functions that are aware of my memory bank switching, and I have a mmap function that will use zero page fault handlers to bank switch, map, and unmap regions to provide a linear appearance to user space. BUT, it seems that the logo code, and possibly some other things still want to touch the video memory. This can't happen! I saw reference to an imageblit function in some documents but it may be from an older implementation. Clearly that is what I need since I cannot allow anyone outside my driver to directly access memory pointers. Can someone offer some advice as to what I should do to prevent the logo code and others from touching my memory pointers. Second, there is no reason that driver private information should be provided outside the driver. Can we make sure that these things go away in the redesign (I haven't looked though the new code yet, hopefully such nonsense is gone already) -Matt |
|
From: Patrick M. <mo...@in...> - 2001-11-16 17:49:26
|
I am only half-paying attention and I saw my name... On Fri, 16 Nov 2001, James Simmons wrote: > > > >Where can I find this work or is it vaporware? As how stable is it? Will > > >it be the final solution that will go in? I like to port a few subsystems > > >in my CVS to it. > > > > > >> Speaking of this.. do you know what the plans for ddfs are? > > > > > >Yet another device filesystem? The nice thing about a new unified device > > >interface is it will make the device filesystems I plan to work much > > >easier to implement. > > > > Ask Patrick and the linux mailing list. AFAIK, His current patches not > > only provide the unified struct device with PM hooks, but also the > > device filesystem. > > Good. I sent out the email. Also if he has a very mature device filesystem > that will make our lives easier. The code lives on kernel.org: ftp://ftp.kernel.org/pub/linux/kernel/people/mochel/device There is a document that should be relatively up to date describing what's going on. The gist of it is that it provides a unified device tree based on locality. Nodes are added by the bus drivers on which a device sits. So, the PCI layer adds nodes for all devices that it finds when probing the bus. There is also a filesystem that goes along with it and presents this unified view to userspace. The power management code is not explicitly included in that code. I have implemented one suspend/resume transition, but it is in the ACPI subsystem, which you can get from Intel: http://developer.intel.com/technology/IAPC/acpi/index.htm I have thought about doing a general PM imeplementation, but probably will not, since there are too many platform-specific things that you must worry about to make it elegant.. -pat |
|
From: James S. <jsi...@tr...> - 2001-11-16 17:32:11
|
> >Where can I find this work or is it vaporware? As how stable is it? Will > >it be the final solution that will go in? I like to port a few subsystems > >in my CVS to it. > > > >> Speaking of this.. do you know what the plans for ddfs are? > > > >Yet another device filesystem? The nice thing about a new unified device > >interface is it will make the device filesystems I plan to work much > >easier to implement. > > Ask Patrick and the linux mailing list. AFAIK, His current patches not > only provide the unified struct device with PM hooks, but also the > device filesystem. Good. I sent out the email. Also if he has a very mature device filesystem that will make our lives easier. |
|
From: Benjamin H. <be...@ke...> - 2001-11-16 14:14:49
|
>Ask Patrick and the linux mailing list. AFAIK, His current patches not >only provide the unified struct device with PM hooks, but also the >device filesystem. I mean linux-kernel mailing list of course ;) Ben. |
|
From: Jani M. <ja...@as...> - 2001-11-16 14:13:05
|
Hi there's an initial fb driver for Trident Blade cards and limited support for Image acceleration.It is ugly but testable :) http://sf.net/projects/tridentfb Sorry if I posted to the wrong list Jani. |
|
From: Benjamin H. <be...@ke...> - 2001-11-16 13:51:27
|
>> > You may want to sync with Patrick Mochel who is working on the new >> > PM scheme for 2.5 along with the new unified device interface. >> > AFAIK, pm_dev will be gone and all devices will have PM hooks as >> > part of the standard "struct device" that _any_ HW driver will >> > be supposed to implement. > >Where can I find this work or is it vaporware? As how stable is it? Will >it be the final solution that will go in? I like to port a few subsystems >in my CVS to it. > >> Speaking of this.. do you know what the plans for ddfs are? > >Yet another device filesystem? The nice thing about a new unified device >interface is it will make the device filesystems I plan to work much >easier to implement. Ask Patrick and the linux mailing list. AFAIK, His current patches not only provide the unified struct device with PM hooks, but also the device filesystem. Ben. |
|
From: James S. <jsi...@tr...> - 2001-11-15 17:24:41
|
> > You may want to sync with Patrick Mochel who is working on the new > > PM scheme for 2.5 along with the new unified device interface. > > AFAIK, pm_dev will be gone and all devices will have PM hooks as > > part of the standard "struct device" that _any_ HW driver will > > be supposed to implement. Where can I find this work or is it vaporware? As how stable is it? Will it be the final solution that will go in? I like to port a few subsystems in my CVS to it. > Speaking of this.. do you know what the plans for ddfs are? Yet another device filesystem? The nice thing about a new unified device interface is it will make the device filesystems I plan to work much easier to implement. |
|
From: Jeff G. <jg...@ma...> - 2001-11-14 23:32:57
|
Paul Mundt wrote: > Just a minor cleanup.. in the event of some sanity checking in fb_mmap(), the > BKL is accidentally held on a return.. this trivial patch fixes this issue. No idea why your patch didn't apply here, but it didn't. Attached is the same fix patch, rediff'd against 2.4.15-pre4. Jeff -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno |
|
From: Paul M. <pm...@mv...> - 2001-11-14 23:26:40
|
Hello,
Just a minor cleanup.. in the event of some sanity checking in fb_mmap(), t=
he
BKL is accidentally held on a return.. this trivial patch fixes this issue.
(Against 2.4.14).
Please apply.
Regards,
--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.
--- linux/drivers/video/fbmem.c.orig Wed Nov 14 15:17:40 2001
+++ linux/drivers/video/fbmem.c Wed Nov 14 15:17:50 2001
@@ -563,8 +563,10 @@
/* memory mapped io */
off -=3D len;
fb->fb_get_var(&var, PROC_CONSOLE(info), info);
- if (var.accel_flags)
+ if (var.accel_flags) {
+ unlock_kernel();
return -EINVAL;
+ }
start =3D fix.mmio_start;
len =3D PAGE_ALIGN((start & ~PAGE_MASK)+fix.mmio_len);
}
|
|
From: James S. <jsi...@tr...> - 2001-11-14 23:05:30
|
I just tried this driver out and I just got a blank screen. So I'm wondering can this card be used stand alone or do I have to hook it up to abnother card? |
|
From: Paul M. <pm...@mv...> - 2001-11-14 23:04:06
|
On Wed, Nov 14, 2001 at 11:56:10PM +0100, Benjamin Herrenschmidt wrote: > You may want to sync with Patrick Mochel who is working on the new > PM scheme for 2.5 along with the new unified device interface. > AFAIK, pm_dev will be gone and all devices will have PM hooks as > part of the standard "struct device" that _any_ HW driver will > be supposed to implement. >=20 Speaking of this.. do you know what the plans for ddfs are? Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: Benjamin H. <be...@ke...> - 2001-11-14 22:57:01
|
> >Hm. Code in fbmem.c can handle this. Actually I like to make the blank >code more robust. I like to see real power management on alot of levels. >For example many hand held devices have hooks to lower the pixclock when >in power saving mode. This is needed when you lower the CPU clock speed. >We really should be making use of the struct pm_dev I placed into struct >fb_info. So to deal with this issue in fbmem we could atomically read >struct pm_dev state field. > >P.S > No power management function to read the current state? You may want to sync with Patrick Mochel who is working on the new PM scheme for 2.5 along with the new unified device interface. AFAIK, pm_dev will be gone and all devices will have PM hooks as part of the standard "struct device" that _any_ HW driver will be supposed to implement. Ben. |
|
From: James S. <jsi...@tr...> - 2001-11-14 22:24:34
|
> * Note: If screen is blanked, all other functions (setcolreg, > * imageblit) may be still invoked, and must work. This needs > * special care if you are blanking by programming DAC to all black. > > or something like that. See other email. > > * Returns negative errno on error, or zero on success. > > If driver does not support specified powerdown mode, should it > use nearest mode with greater power consumption, nearest mode with > smaller power consumption, or should it report an error? > ? * If we have no hardware acceleration, we provide an unaccelerated > ? * functions in fbcon-cfb*.c modules. You can use these functions > ? * as fallbacks if hardware unsupported action is requested. Yes this is the case. I have three different files each with a soft accel for each possible accel function. The reason for breaking them up is because in theory you could have a device with only fillrect support. Then you can plug in the other two generic accel functions. As for non pack pixel and non accelerated cards you have to provide your own functions. > Move #endif up below xxxfb_init, as these macros works correctly > when code is built into kernel, and we want to make sure that nobody > will remove #ifdef MODULE when doing cleanup, as we still call > init explicitly from global fb initialization. Done :-) |
|
From: James S. <jsi...@tr...> - 2001-11-14 22:09:24
|
> > What about: > > > > * Note: If screen is blanked, all other functions (setcolreg, > > * imageblit) may be still invoked, and must work. This needs > > * special care if you are blanking by programming DAC to all black. > > > > or something like that. > > Or the upper layer could take care of that. Hm. Code in fbmem.c can handle this. Actually I like to make the blank code more robust. I like to see real power management on alot of levels. For example many hand held devices have hooks to lower the pixclock when in power saving mode. This is needed when you lower the CPU clock speed. We really should be making use of the struct pm_dev I placed into struct fb_info. So to deal with this issue in fbmem we could atomically read struct pm_dev state field. P.S No power management function to read the current state? |
|
From: James S. <jsi...@tr...> - 2001-11-14 21:52:02
|
> > Hi folks. I finally hammered a newer api for framebuffer devices. I
> > adapted skeletonfb.c to show it off. Feedback welcomed.
>
> Good news!
A few drivers have been converted over to it :-)
> > /*
> > * If your driver supports multiple boards, you should make these
> > * arrays, or allocate them dynamically (using kmalloc()).
> > */
>
> Perhaps make it more clear that this applies to all 3 (4?) variables below
I should. In reality all of them can be dynamically allocated.
> > /**
> > * xxxfb_check_var - REQUIRED function. Validates a var passed in.
>
> Is this function really required? Imagine a graphics card with a fixed
> resolution (e.g. old Sun3 bwtwo), or vesafb/offb.
>
> If it's NULL, you cannot change var, and upper layer can check that an
> identical var was passed (using memcmp()).
Wait. Your right. In CVS I made it optional. I missed updating this. If
you can change the mode it just returns the current mode instead.
if (!info->fbops->fb_check_var) {
*var = info->var;
return 0;
}
> > * xxxfb_setcolreg - REQUIRED function. Sets a color register.
>
> Is this function really required? Imagine static pseudocolor (fixed palette)
> hardware.
I never thought about that. Your right. Will fix.
> > /* Truecolor has hardware independent palette */
> > if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> > u32 v;
> >
> > if (regno >= 16)
> > return 1;
> >
> > v = (red << info->var.red.offset) |
> > (green << info->var.green.offset) |
> > (blue << info->var.blue.offset) |
> > (transp << info->var.transp.offset);
> > if (info->var.bits_per_pixel == 16)
> > ((u16*)(info->pseudo_palette))[regno] = v;
> > else
> > ((u32*)(info->pseudo_palette))[regno] = v;
> > return 0;
>
> What about info->var.bits_per_pixel == 8? Some handhelds are RGB332 truecolor.
Your right again. Even the Matrox millenium could do this mode. I will add
as a example. Made changes to skeletonfb.c.
|
|
From: Geert U. <ge...@li...> - 2001-11-14 21:06:55
|
On Wed, 14 Nov 2001 he...@ho... wrote:
> James Simmons writes:
> > Hi folks. I finally hammered a newer api for framebuffer devices. I
> > adapted skeletonfb.c to show it off. Feedback welcomed.
> >
> > /*
> > * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
> > *
> ...
> > /**
> > * xxxfb_imageblit - REQUIRED function. Can use generic routines if
> > * non acclerated hardware and packed pixel based.
> > * Copies a image from system memory to the screen.
> > *
> > * @info: frame buffer structure that represents a single frame buffer
> > * @image: structure defining the image.
> > *
> > * This drawing operation draws a image on the screen. It can be a
> > * mono image (needed for font handling) or a color image (needed for
> > * tux).
> > */
> > void xxxfb_imageblit(struct fb_info *p, struct fb_image *image)
> > {
> > }
>
> Which bit ordering will be used? Leftmost = MSb (as in console fonts)
> or leftmost = LBb (as in XFree, at least in nVidia driver, which I'm
> familiar with)?
Kernel fonts wider than 8 pixels have always been big-endian.
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
|
|
From: Geert U. <ge...@li...> - 2001-11-14 21:06:15
|
On Wed, 14 Nov 2001, Petr Vandrovec wrote:
> On 14 Nov 01 at 11:58, James Simmons wrote:
> > * Blank the screen if blank_mode != 0, else unblank. Return 0 if
> > * blanking succeeded, != 0 if un-/blanking failed due to e.g. a
> > * video mode which doesn't support it. Implements VESA suspend
> > * and powerdown modes on hardware that supports disabling hsync/vsync:
> > * blank_mode == 2: suspend vsync
> > * blank_mode == 3: suspend hsync
> > * blank_mode == 4: powerdown
>
> What about:
>
> * Note: If screen is blanked, all other functions (setcolreg,
> * imageblit) may be still invoked, and must work. This needs
> * special care if you are blanking by programming DAC to all black.
>
> or something like that.
Or the upper layer could take care of that.
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
|
|
From: Geert U. <ge...@li...> - 2001-11-14 21:04:15
|
On Wed, 14 Nov 2001, James Simmons wrote:
> Hi folks. I finally hammered a newer api for framebuffer devices. I
> adapted skeletonfb.c to show it off. Feedback welcomed.
Good news!
> /*
> * If your driver supports multiple boards, you should make these
> * arrays, or allocate them dynamically (using kmalloc()).
> */
Perhaps make it more clear that this applies to all 3 (4?) variables below
> static struct fb_info info;
> /*
> * This represents the default state of the hardware.
> */
> static struct xxx_par __initdata current_par;
>
> static u32 xxxfb_pseudo_palette[17];
> static int inverse = 0;
> /**
> * xxxfb_check_var - REQUIRED function. Validates a var passed in.
Is this function really required? Imagine a graphics card with a fixed
resolution (e.g. old Sun3 bwtwo), or vesafb/offb.
If it's NULL, you cannot change var, and upper layer can check that an
identical var was passed (using memcmp()).
> * xxxfb_setcolreg - REQUIRED function. Sets a color register.
Is this function really required? Imagine static pseudocolor (fixed palette)
hardware.
> /* Directcolor:
> * var->{color}.offset contains start of bitfield
> * var->{color}.length contains length of bitfield
> * {hardwarespecific} contains width of DAC
> * cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
> * DAC[X] is programmed to (red, green, blue)
s/DAC/RAMDAC/
> *
> * Pseudocolor:
> * uses offset = 0 && length = DAC register width.
> * var->{color}.offset is 0
> * var->{color}.length contains widht of DAC
> * cmap is not used
> * DAC[X] is programmed to (red, green, blue)
s/DAC/RAMDAC/
> * Truecolor:
> * does not use DAC.
> * var->{color}.offset contains start of bitfield
> * var->{color}.length contains length of bitfield
> * cmap is programmed to (red << red.offset) | (green << green.offset) |
> * (blue << blue.offset) | (transp << transp.offset)
> * DAC does not exist
s/DAC/RAMDAC/
Truecolor does have a DAC (even 3 of them :-), but no RAMDAC.
> /* Truecolor has hardware independent palette */
> if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> u32 v;
>
> if (regno >= 16)
> return 1;
>
> v = (red << info->var.red.offset) |
> (green << info->var.green.offset) |
> (blue << info->var.blue.offset) |
> (transp << info->var.transp.offset);
> if (info->var.bits_per_pixel == 16)
> ((u16*)(info->pseudo_palette))[regno] = v;
> else
> ((u32*)(info->pseudo_palette))[regno] = v;
> return 0;
What about info->var.bits_per_pixel == 8? Some handhelds are RGB332 truecolor.
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
|
|
From: <he...@ho...> - 2001-11-14 20:28:01
|
James Simmons writes:
>
> Hi folks. I finally hammered a newer api for framebuffer devices. I
> adapted skeletonfb.c to show it off. Feedback welcomed.
>
> /*
> * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
> *
...
> /**
> * xxxfb_imageblit - REQUIRED function. Can use generic routines if
> * non acclerated hardware and packed pixel based.
> * Copies a image from system memory to the screen.
> *
> * @info: frame buffer structure that represents a single frame buffer
> * @image: structure defining the image.
> *
> * This drawing operation draws a image on the screen. It can be a
> * mono image (needed for font handling) or a color image (needed for
> * tux).
> */
> void xxxfb_imageblit(struct fb_info *p, struct fb_image *image)
> {
> }
Which bit ordering will be used? Leftmost = MSb (as in console fonts)
or leftmost = LBb (as in XFree, at least in nVidia driver, which I'm
familiar with)?
--
Jindrich Makovicka
|
|
From: Petr V. <VAN...@vc...> - 2001-11-14 20:24:32
|
On 14 Nov 01 at 11:58, James Simmons wrote:
> Hi folks. I finally hammered a newer api for framebuffer devices. I
> adapted skeletonfb.c to show it off. Feedback welcomed.
Thanks.
> * Blank the screen if blank_mode != 0, else unblank. Return 0 if
> * blanking succeeded, != 0 if un-/blanking failed due to e.g. a
> * video mode which doesn't support it. Implements VESA suspend
> * and powerdown modes on hardware that supports disabling hsync/vsync:
> * blank_mode == 2: suspend vsync
> * blank_mode == 3: suspend hsync
> * blank_mode == 4: powerdown
What about:
* Note: If screen is blanked, all other functions (setcolreg,
* imageblit) may be still invoked, and must work. This needs
* special care if you are blanking by programming DAC to all black.
or something like that.
> * Returns negative errno on error, or zero on success.
If driver does not support specified powerdown mode, should it
use nearest mode with greater power consumption, nearest mode with
smaller power consumption, or should it report an error?
> /*
> * We provide our own functions if we have hardware acceleration
> * or non packed pixel format layouts.
? * If we have no hardware acceleration, we provide an unaccelerated
? * functions in fbcon-cfb*.c modules. You can use these functions
? * as fallbacks if hardware unsupported action is requested.
> * xxxfb_fillrect - REQUIRED function. Can use generic routines if
> * non acclerated hardware and packed pixel based.
> * Draws a rectangle on the screen.
filled rectangle, I assume, not two horizontal and
two vertical lines...
> *
> * @info: frame buffer structure that represents a single frame buffer
> #ifdef MODULE
> module_init(xxxfb_init);
> module_exit(xxxfb_cleanup);
>
> MODULE_LICENSE("GPL");
> #endif /* MODULE */
Move #endif up below xxxfb_init, as these macros works correctly
when code is built into kernel, and we want to make sure that nobody
will remove #ifdef MODULE when doing cleanup, as we still call
init explicitly from global fb initialization. I do not need it on
my systems (due to pciorder patch), but others may use non-PCI devices,
so we probably want to retain this :-( Unless there is another
devices ordering scheme planned for 2.5.
Petr Vandrovec
van...@vc...
|
|
From: James S. <jsi...@tr...> - 2001-11-14 19:59:05
|
Hi folks. I finally hammered a newer api for framebuffer devices. I
adapted skeletonfb.c to show it off. Feedback welcomed.
/*
* linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
*
* Modified to new api Jan 2001 by James Simmons (jsi...@tr...)
*
* Created 28 Dec 1997 by Geert Uytterhoeven
*
*
* I have started rewriting this driver as a example of the upcoming new API
* The primary goal is to remove the console code from fbdev and place it
* into fbcon.c. This reduces the code and makes writing a new fbdev driver
* easy since the author doesn't need to worry about console internals. It
* also allows the ability to run fbdev without a console system on top of it.
*
* First the roles of struct fb_info and struct display have changed. Struct
* display has gone away. The upper framebuffer console layer only depends on
* fb_info. For each framebuffer device when used as a VT console is allocate
* a set of virtual terminals to it. Only one virtual terminal can be active
* per framebuffer device. So I have struct fb_info represent all the data of
* the current hardware state of the framebuffer. Meaning the resolution of
* the active VT (the one you're looking at) and other data is stored in the
* fb_info struct. When you VT switch the current video state is translated
* to a form to be stored by the the higher level console layer to be stored
* for that terminal you just switched away from. Then the current video
* state is set to the data values stored in the upper console layer for the
* virtual terminal you are switching to. As you can see doing this makes
* the con parameter pretty much useless for the fb_ops functions, as it
* should be. Also having fb_var_screeninfo and other data in fb_info pretty
* much eliminates the need for get_fix and get_var. Once all drivers use the
* fix, var, and cmap field fbcon can be written around these fields. This
* will also eliminate the need to regenerate fb_var_screeninfo and
* fb_fix_screeninfo data every time the get_var and get_fix functions are
* called as many drivers do now. The fb_var_screeninfo and
* fb_fix_screeninfo field in fb_info can be generated just in set_var and
* placed into struct fb_info.
*
* 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/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/tty.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/init.h>
/*
* This is just simple sample code.
*
* No warranty that it actually compiles.
* Even less warranty that it actually works :-)
*/
/*
* This structure defines the hardware state of the graphics card. Normally
* you place this in a header file in linux/include/video. This file usually
* also includes register information. That allows other driver subsystems
* and userland applications the ability to use the same header file to
* avoid duplicate work and easy porting of software.
*/
struct xxx_par;
/*
* Here we define the default structs fb_fix_screeninfo and fb_var_screeninfo
* if we don't use modedb. If we do use modedb see xxxfb_init how to use it
* to get a fb_var_screeninfo. Otherwise define a default var as well.
*/
static struct fb_fix_screeninfo xxxfb_fix __initdata = {
"FB's name", (unsigned long) NULL, 0, FB_TYPE_PACKED_PIXELS, 0,
FB_VISUAL_PSEUDOCOLOR, 1, 1, 1, 0, (unsigned long) NULL, 0, FB_ACCEL_NONE
};
/*
* Modern graphical hardware not only supports pipelines but some
* also support multiple monitors where each display can have its
* its own unique data. In this case each display could be
* represented by a seperate framebuffer device thus a seperate
* struct fb_info. In this case all of the par structures for the
* graphics card would be shared between each struct fb_info. This
* allows when one display changes it video resolution (info->var)
* the other displays know instantly. Each display can always be
* aware of the entire hardware state that affects it. The other side
* of the coin is multiple graphics cards that pass data around until
* it is finally displayed on one monitor. Such examples are the
* voodoo 1 cards and high end NUMA graphics servers. I hope this
* covers every possible hardware design. If not feel free to send
* me more design types.
*/
/*
* If your driver supports multiple boards, you should make these
* arrays, or allocate them dynamically (using kmalloc()).
*/
static struct fb_info info;
/*
* This represents the default state of the hardware.
*/
static struct xxx_par __initdata current_par;
static u32 xxxfb_pseudo_palette[17];
static int inverse = 0;
int xxxfb_init(void);
int xxxfb_setup(char*);
/**
* xxxfb_check_var - REQUIRED function. Validates a var passed in.
* @var: frame buffer variable screen structure
* @info: frame buffer structure that represents a single frame buffer
*
* Checks to see if the hardware supports the state requested by
* var passed in. This function does not alter the hardware state!!!
* This means the data stored in fb_info, par and var, do not change.
* Do NOT change these. This function can be called on its own if we
* intent to only test a mode and not actually set it. The stuff in
* modedb.c is a example of this. If the var passed in is slightly
* off by what the hardware can support then we alter the var PASSED in
* to what we can do. If the hardware doesn't support mode change
* just return a -EINVAL;
*
* Returns negative errno on error, or zero on success.
*/
static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
const struct xxx_par *par = (const struct xxx_par *) info->par;
/* ... */
return 0;
}
/**
* xxxfb_set_par - NOT a required function. Alters the hardware state.
* @info: frame buffer structure that represents a single frame buffer
*
* Using the fb_var_screeninfo in fb_info we set the resolution of the
* this particular framebuffer. This function alters the par AND the
* fb_fix_screeninfo stored in fb_info. It doesn't not alter var in
* fb_info since we are using that data. This means we depend on the
* data in var inside fb_info to be supported by the hardware.
* xxxfb_check_var is always called before xxxfb_set_par to ensure this.
*
*/
static void xxxfb_set_par(struct fb_info *info)
{
struct xxx_par *par = (struct xxx_par *) info->par;
/* ... */
}
/**
* xxxfb_setcolreg - REQUIRED function. Sets a color register.
* @regno: boolean, 0 copy local, 1 get_user() function
* @red: frame buffer colormap structure
* @green: The green value which can be up to 16 bits wide
* @blue: The blue value which can be up to 16 bits wide.
* @transp: If supported the alpha value which can be up to 16 bits wide.
* @info: frame buffer info structure
*
* Set a single color register. The values supplied have a 16 bit
* magnitude which needs to be scaled in this function for the hardware.
* Things to take into consideration are how many color registers, if
* any, are supported with the current color visual. With truecolor mode
* no color palettes are supported. Here a psuedo palette is created
* which we store the value in pseudo_palette in struct fb_info. For
* pseudocolor mode we have a limited color palette. To deal with this
* we can program what color is displayed for a particular pixel value.
* DirectColor is similar in that we can program each color field.
*
* Returns negative errno on error, or zero on success.
*/
static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
unsigned blue, unsigned transp,
const struct fb_info *info)
{
if (regno >= 256) /* no. of hw registers */
return 1;
/*
* Program hardware... do anything you want with transp
*/
/* grayscale works only partially under directcolor */
if (info->var.grayscale) {
/* grayscale = 0.30*R + 0.59*G + 0.11*B */
red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
}
/* Directcolor:
* var->{color}.offset contains start of bitfield
* var->{color}.length contains length of bitfield
* {hardwarespecific} contains width of DAC
* cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
* DAC[X] is programmed to (red, green, blue)
*
* Pseudocolor:
* uses offset = 0 && length = DAC register width.
* var->{color}.offset is 0
* var->{color}.length contains widht of DAC
* cmap is not used
* DAC[X] is programmed to (red, green, blue)
* Truecolor:
* does not use DAC.
* var->{color}.offset contains start of bitfield
* var->{color}.length contains length of bitfield
* cmap is programmed to (red << red.offset) | (green << green.offset) |
* (blue << blue.offset) | (transp << transp.offset)
* DAC does not exist
*/
#define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
switch (info->fix.visual) {
case FB_VISUAL_TRUECOLOR:
case FB_VISUAL_PSEUDOCOLOR:
red = CNVT_TOHW(red, info->var.red.length);
green = CNVT_TOHW(green, info->var.green.length);
blue = CNVT_TOHW(blue, info->var.blue.length);
transp = CNVT_TOHW(transp, info->var.transp.length);
break;
case FB_VISUAL_DIRECTCOLOR:
/* example here assumes 8 bit DAC. Might be different
* for your hardware */
red = CNVT_TOHW(red, 8);
green = CNVT_TOHW(green, 8);
blue = CNVT_TOHW(blue, 8);
/* hey, there is bug in transp handling... */
transp = CNVT_TOHW(transp, 8);
break;
}
#undef CNVT_TOHW
/* Truecolor has hardware independent palette */
if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
u32 v;
if (regno >= 16)
return 1;
v = (red << info->var.red.offset) |
(green << info->var.green.offset) |
(blue << info->var.blue.offset) |
(transp << info->var.transp.offset);
if (info->var.bits_per_pixel == 16)
((u16*)(info->pseudo_palette))[regno] = v;
else
((u32*)(info->pseudo_palette))[regno] = v;
return 0;
}
/* ... */
return 0;
}
/**
* xxxfb_pan_display - NOT a required function. Pans the display.
* @var: frame buffer variable screen structure
* @info: frame buffer structure that represents a single frame buffer
*
* Pan (or wrap, depending on the `vmode' field) the display using the
* `xoffset' and `yoffset' fields of the `var' structure.
* If the values don't fit, return -EINVAL.
*
* Returns negative errno on error, or zero on success.
*
*/
static int xxxfb_pan_display(struct fb_var_screeninfo *var,
const struct fb_info *info)
{
/* ... */
return 0;
}
/**
* xxxfb_blank - NOT a required function. Blanks the display.
* @blank_mode: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*
* Blank the screen if blank_mode != 0, else unblank. Return 0 if
* blanking succeeded, != 0 if un-/blanking failed due to e.g. a
* video mode which doesn't support it. Implements VESA suspend
* and powerdown modes on hardware that supports disabling hsync/vsync:
* blank_mode == 2: suspend vsync
* blank_mode == 3: suspend hsync
* blank_mode == 4: powerdown
*
* Returns negative errno on error, or zero on success.
*
*/
static int xxxfb_blank(int blank_mode, const struct fb_info *info)
{
/* ... */
return 0;
}
/* ------------ Accelerated Functions --------------------- */
/*
* We provide our own functions if we have hardware acceleration
* or non packed pixel format layouts.
*/
/**
* xxxfb_fillrect - REQUIRED function. Can use generic routines if
* non acclerated hardware and packed pixel based.
* Draws a rectangle on the screen.
*
* @info: frame buffer structure that represents a single frame buffer
* @x1: The x and y corrdinates of the upper left hand corner of the
* @y1: area we want to draw to.
* @width: How wide the rectangle is we want to draw.
* @height: How tall the rectangle is we want to draw.
* @color: The color to fill in the rectangle with.
* @rop: The rater operation. We can draw the rectangle with a COPY
* of XOR which provides erasing effect.
*
* This drawing operation places/removes a retangle on the screen
* depending on the rastering operation with the value of color which
* is in the current color depth format.
*/
void xxxfb_fillrect(struct fb_info *p, int x1, int y1, unsigned int width,
unsigned int height, unsigned long color, int rop)
{
}
/**
* xxxfb_copyarea - REQUIRED function. Can use generic routines if
* non acclerated hardware and packed pixel based.
* Copies on area of the screen to another area.
*
* @info: frame buffer structure that represents a single frame buffer
* @sx: The x and y corrdinates of the upper left hand corner of the
* @sy: source area on the screen.
* @width: How wide the rectangle is we want to copy.
* @height: How tall the rectangle is we want to copy.
* @dx: The x and y coordinates of the destination area on the screen.
*
* This drawing operation copies a rectangular area from one area of the
* screen to another area.
*/
void xxxfb_copyarea(struct fb_info *p, int sx, int sy, unsigned int width,
unsigned int height, int dx, int dy)
{
}
/**
* xxxfb_imageblit - REQUIRED function. Can use generic routines if
* non acclerated hardware and packed pixel based.
* Copies a image from system memory to the screen.
*
* @info: frame buffer structure that represents a single frame buffer
* @image: structure defining the image.
*
* This drawing operation draws a image on the screen. It can be a
* mono image (needed for font handling) or a color image (needed for
* tux).
*/
void xxxfb_imageblit(struct fb_info *p, struct fb_image *image)
{
}
/* ------------ Hardware Independent Functions ------------ */
/*
* Initialization
*/
int __init xxxfb_init(void)
{
int retval;
/*
* Here we set the screen_base to the vitrual memory address
* for the framebuffer. Usually we obtain the resource address
* from the bus layer and then translate it to virtual memory
* space via ioremap. Consult ioport.h.
*/
info.screen_base = framebuffer_virtual_memory;
info.node = -1;
info.fbops = &xxxfb_ops;
info.fix = xxxfb_fix;
info.par = current_par;
info.pseudo_palette = xxxfb_pseudo_palette;
info.flags = FBINFO_FLAG_DEFAULT;
/* This should give a reasonable default video mode */
if (!mode_option)
mode_option = "640x480@60";
retval = fb_find_mode(&info.var, &info, mode_option, NULL, 0, NULL, 8);
if (!retval || retval == 4)
return -EINVAL;
info.cmap = fb_default_cmap(1<<info.var.bits_per_pixel);
if (register_framebuffer(&info) < 0)
return -EINVAL;
printk(KERN_INFO "fb%d: %s frame buffer device\n", GET_FB_IDX(info.node),
info.fix.id);
/* uncomment this if your driver cannot be unloaded */
/* MOD_INC_USE_COUNT; */
return 0;
}
/*
* Cleanup
*/
static void __exit xxxfb_cleanup(void)
{
/*
* If your driver supports multiple boards, you should unregister and
* clean up all instances.
*/
unregister_framebuffer(info);
/* ... */
}
/*
* Setup
*/
/*
* Only necessary if your driver takes special options,
* otherwise we fall back on the generic fb_setup().
*/
int __init xxxfb_setup(char *options)
{
/* Parse user speficied options (`video=xxxfb:') */
}
/* ------------------------------------------------------------------------- */
/*
* Frame buffer operations
*/
/* If all you need is that - just don't define ->fb_open */
static int xxxfb_open(const struct fb_info *info, int user)
{
return 0;
}
/* If all you need is that - just don't define ->fb_release */
static int xxxfb_release(const struct fb_info *info, int user)
{
return 0;
}
static struct fb_ops xxxfb_ops = {
owner: THIS_MODULE,
fb_open: xxxfb_open, /* only if you need it to do something */
fb_release: xxxfb_release, /* only if you need it to do something */
fb_check_var: xxxfb_check_var,
fb_set_par: xxxfb_set_par, /* optional */
fb_setcolreg: xxxfb_setcolreg,
fb_blank: xxxfb_blank, /* optional */
fb_pan_display: xxxfb_pan_display, /* optional */
fb_fillrect: xxxfb_fillrect,
fb_copyarea: xxxfb_copyarea,
fb_imageblit: xxxfb_imageblit,
fb_ioctl: xxxfb_ioctl, /* optional */
fb_mmap: xxxfb_mmap, /* optional */
};
/* ------------------------------------------------------------------------- */
/*
* Modularization
*/
#ifdef MODULE
module_init(xxxfb_init);
module_exit(xxxfb_cleanup);
MODULE_LICENSE("GPL");
#endif /* MODULE */
|
|
From: Petr V. <VAN...@vc...> - 2001-11-14 18:04:00
|
On 14 Nov 01 at 9:57, James Simmons wrote:
> > I think that it is much easier to create an
> >
> > In such case you have much better control over specified options
> > command line, you can parse some options in special way, you can
> > specify fbdev own defaults for fb_info fields, ... And you do not
> > have to change API. But I think that you all know my position very well.
>
> This is pretty close to what we have in CVS. Of course doing it this way
> means every framebuffer driver needs its own setup function.
It needs it anyway, AFAIK. Or is there some fbdev driver which is
completely PnP? Maybe sbus* driver family, and for them you can create
fb_default_setup(), which will just retry calls to parse general parameter
for every strsep() result. In such case we have small default setup
for PnP framebuffers, and still complicated/unconfigurable framebuffers can
complain on specified unsupported arguments, or accept its own parameters.
Petr Vandrovec
van...@vc...
|
|
From: James S. <jsi...@tr...> - 2001-11-14 17:57:15
|
> I think that it is much easier to create an
>
> int is_it_a_general_framebuffer_option(struct fb_info* fbi,
> const char* option);
>
> and then in driver do:
>
> while ((this_opt = strsep(&options, ",")) != NULL) {
> if (!*this_opt) continue;
> if (is_it_a_general_framebuffer_option(fbi, this_opt)) continue;
> if (strcmp(this_opt, "....")) ...
> }
>
> In such case you have much better control over specified options
> command line, you can parse some options in special way, you can
> specify fbdev own defaults for fb_info fields, ... And you do not
> have to change API. But I think that you all know my position very well.
This is pretty close to what we have in CVS. Of course doing it this way
means every framebuffer driver needs its own setup function.
|
754 messages has been excluded from this view by a project administrator.
