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: Michel <mi...@da...> - 2002-10-18 19:28:48
|
On Fre, 2002-10-18 at 19:21, Nicholas Wourms wrote: > Michel D=E4nzer wrote: >=20 > > On Mit, 2002-10-16 at 22:55, Nicholas Wourms wrote: > >>=20 > >> A) Is it (or will it ever be) possible to run dual head > >> using two different cards (like radeon & riva-tnt2)? I know > >> there is still much work to be done, but I was curious if > >> this was even remotely possible. > >=20 > > I think it should theoretically work, but as always the only way to tel= l > > is to try it. :) >=20 > Well there isn't much on multiheading in the documentation, so I was hopi= ng=20 > for some hints or key insights into how to set this up. Something like video=3Dradeonfb video=3Driva ? > >> B) Does anyone have a painless, yet precise way of > >> generating modelines for fb.modes if you are using > >> XFree-4.2? I only ask because the XFree modelines are all > >> determined by i2c DDC probing, thus there are none in the > >> XF86Config file. > >=20 > > If the X driver supports Option "UseFBDev", you should be able to use > > fbset with that. > >=20 >=20 > Huh? The problem is that fbset will not work because I need to populate=20 > fb.modes with proper mode lines. So at the moment fbset won't work at al= l. =20 I was thinking of running X with Option "UseFBDev" and getting information about the modes with fbset. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Russell K. <rm...@ar...> - 2002-10-18 18:33:03
|
On Fri, Oct 18, 2002 at 10:27:59AM -0700, James Simmons wrote:
> Yes the drivers should always have priority. The other stuff is there
> only if the drivers have no power management of any kind. I leave it up to
> the driver write to implement a fb_blank function that handles different
> cases.
The drivers don't have priority though. You call set_par, and then
wander off into the internals of fbgen.c to set can_soft_blank youself,
without giving the drivers any look-in to set that correctly.
> > There is also the argument about wanting soft blanking, but hardware power
> > saving.
>
> Hm. True unfortunely the fbdev layer lacks handling details like that. The
> console system is even worse. This is why a single flag like
> can_soft_blank can actually be a limitation.
Well, it needs to be fixed. We've lost functionality that was present in
2.4, and therefore I call it a bug.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@in...> - 2002-10-18 18:20:39
|
> I thought i may as well write a little HOWTO or something such on the > way of doing this. Since i have not much fbdev writing experience, maybe > i am a good candidate for writing such a thing. Wow that would be great. > I wanted, in the first step, to do just a basic unaccelerated fbdev > driver, without mode changes and anything fancy, and once this works, > add things incrementally. I believe this approach will be good for > future fbdev driver writters. Good approach to doing this. > Anyway, now for my question. > > skeletonfb says that check_var, set_par, setcolreg, pan_display and > blank functions are optional or not required. Is that true, and in case > i don't want to provide them, whay do i put in the fb_ops structure ? All the functions are optional. They are needed when: fb_open: We need special things done when we open or close /dev/fb fb_release: fb_read: When we have a strange framebuffer that doesn't allow fb_write: linear writes. A good example is the Epson1385 chipset at 16 bpp mode. fb_check_var: When we can change the resolution of the display. fb_set_par: fb_setcolreg: Have a programable color palette. fb_blank: Have hardware support for power management of some kind. fb_pan_display: Hardware scrolling fb_cursor: Hardware cursor. fb_poll: Want to use interrupts such as VLB. fb_sync: To sync the accel engine and framebuffer memory. fb_ioctl: Extra functions you want to support. fb_mmap: Have special memory needs when exposing to userland. fb_rastering: I don't know if we are going to keep this one? The only ones require are the accel functions for drawing on the console. > Later, in the fb_ops structure, only set_par, blank and pan_display are > labeled as optional. That is a mistake. |
|
From: James S. <jsi...@in...> - 2002-10-18 18:09:14
|
> > And what is meaning of image when mask is 1? For b&w cursors > > we need 0, 1, transparent and inverse. > > Note that not all hardware supports inverse. Hm. The best solution to this is support the flag but we need to know if the hardware supports it. The best thing to do is use the a GETCURSOR ioctl call that returns what we can do. > And on some hardware the cursor palette is shared with the screen palette, > that's why I had fb_fix_cursorinfo.crsr_color[12] in the original cursor API. In this case the provided cursor function would use puedopalette in fb_info then. > Yes, it can be difficult to find a _good_ API ;-) We can but we need to provide a way to say we can't do that. |
|
From: James S. <jsi...@in...> - 2002-10-18 17:50:29
|
On Sun, 13 Oct 2002, Benjamin Herrenschmidt wrote: > Ok, I've ported radeonfb, controlfb and platinumfb to the > new API (which is quite nice since allowed me to remove > a whole bunch of cruft from these drivers, good job !) Great!!!! Just let me know when you want them placed into fbdev BK. > However, I'm having a problem: With controlfb and > radeonfb (couldn't test platinum yet but it's very similar > to controlfb), the console is fine in 8 bpp, but text is > plain blue in any higher bit depth (15, 16 or 32). Okay I have seen this problem on a few drivers. It is either a bug in setcolreg which is often copied from one place to another or a bug in the upper levels. I seen this on the atyfb driver happen. > X with "fbdev" driver works fine, so I think setcolreg > works properly. All those drivers are set to DIRECTCOLOR > for these bit depth. Maybe I've missed something about > the pseudo_palette thing (is it documented somewhere ?) > or are there known endian bugs in the cfb_* routines ? I now know it isn't a endian issues since on my little endian machine I have the same problem. I don't know if it is a cfb_* bug. I will try out my tdfx card to see. It has accelerated functions so the error woudln't be there. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@in...> - 2002-10-18 17:36:19
|
> Wouldn't that complicate merges between the kernel and DRI CVS? At any > rate, I think discussion related to the DRI should take place on > dri-devel. Okay the idea of mixing the drivers together was rejected. SO I just moved the entire directory to drivers/video instead. People didn't seem to have problem with that. |
|
From: James S. <jsi...@in...> - 2002-10-18 17:34:44
|
> That's fine for me, but I'd expect other people to find problems with it. > > Would it not be better to allow drivers to decide which type of blanking > they want to use depending on the current parameters set via the set_par > callback? Only the drivers themselves know what their fb_blank method is > capable of performing. Yes the drivers should always have priority. The other stuff is there only if the drivers have no power management of any kind. I leave it up to the driver write to implement a fb_blank function that handles different cases. > I think with the above you'll inadvertently encourage drivers to mundge > the fb_blank function pointer in their set_par method. Why would you have to mess around with the function pointer. Couldn't you just set a flag or fill in a hardware dependent struct that defines what states are possible for hardware power management. Then when fb_blank is called it uses the information to decide which action to take. I think this approach is much more powerful than using a single can_soft_blank flag. I like to get ride of can_soft_blank and allow the driver to decide on this stuff itself. > There is also the argument about wanting soft blanking, but hardware power > saving. Hm. True unfortunely the fbdev layer lacks handling details like that. The console system is even worse. This is why a single flag like can_soft_blank can actually be a limitation. |
|
From: Nicholas W. <nw...@ne...> - 2002-10-18 17:31:08
|
Michel Dänzer wrote: > On Mit, 2002-10-16 at 22:55, Nicholas Wourms wrote: >> >> A) Is it (or will it ever be) possible to run dual head >> using two different cards (like radeon & riva-tnt2)? I know >> there is still much work to be done, but I was curious if >> this was even remotely possible. > > I think it should theoretically work, but as always the only way to tell > is to try it. :) Well there isn't much on multiheading in the documentation, so I was hoping for some hints or key insights into how to set this up. Is there any special magic that the matrox people use to thell the kernel to initialize both framebuffers? > >> B) Does anyone have a painless, yet precise way of >> generating modelines for fb.modes if you are using >> XFree-4.2? I only ask because the XFree modelines are all >> determined by i2c DDC probing, thus there are none in the >> XF86Config file. > > If the X driver supports Option "UseFBDev", you should be able to use > fbset with that. > Huh? The problem is that fbset will not work because I need to populate fb.modes with proper mode lines. So at the moment fbset won't work at all. What I was asking, since the documention was written when XFree 3.x was still in use, was how do I get (calculate) the modelines for fb.modes based on the information the i2c DDC probing XFree-4.2.1 outputs in XFree.0.log? Or is there a better way? What might be cool is if the fb drivers used the lm-sensors(i2c) capabilities to automagically probe the information and set up the most optimal settings. Maybe I'm talking too much about something I'm not all that familiar with... Still, it would be nice =). Cheers, Nicholas |
|
From: James S. <jsi...@in...> - 2002-10-18 17:23:41
|
> So the generic part of the code should behave like this:
>
> if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
> /* use hardware blanking */
> } else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> /* use software blanking */
> } else {
> /* no blanking possible, except for filling the screen with black, which
> is not appropriate (unless we save/restore the contents?) */
> }
>
> Is that OK for you?
I was thinking more like
if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
/* use hardware blanking */
} else if (info->var.accel_flags) {
/* Use hardware fillrect to blank the screen */
info->fbops->fb_fillrect(info, whole_screen);
} else {
/* Nothing avaiable. Use set the colormap to black */
}
What do you think?
|
|
From: James S. <jsi...@in...> - 2002-10-18 17:12:41
|
> I'm not sure this "set var" business has been thought out as much as it > should be. <snip> I see it coming. With the next set of changes it will be possible to have fbdev with the VT system. So I have been putting into place the ability to power down the framebuffer via the ioctl. So I want the flow to be with fbcon from high level console to fbcon layer to fbdev driver. Without fbcon to go from userland to the fbdev driver directly. Also we have mode changing. Soon I will add hooks to the VT layer to allow use to change a single VC via stty. VT_RESIZE can replace the current method of changing the size of all VCS instead of the fbdev layer doing it. So you will see the necessary changes to handle all this. |
|
From: James S. <jsi...@in...> - 2002-10-18 16:54:43
|
Done. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net On Tue, 15 Oct 2002, Geert Uytterhoeven wrote: > On Mon, 14 Oct 2002, James Simmons wrote: > > > On Sun, 13 Oct 2002, James Simmons wrote: > > > > This is nearly the last of the fbdev api changes (90% of them). Alot of > > > > driver fixes as well. The console related stuff in each fbdev driver > > > > is nearly gone!!! Please do a pull. Thank you. > > > > > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > > > > > Please add the output of diffstat, so we know which files you changed. > > > > Better yet here is the BK patch via email. > > @@ -220,12 +218,7 @@ > > bool ' Advanced low level driver options' CONFIG_FBCON_ADVANCED > > if [ "$CONFIG_FBCON_ADVANCED" = "y" ]; then > > tristate ' Monochrome support' CONFIG_FBCON_MFB > > CONFIG_FBCON_MFB can be deleted, because of this change to the Makefile: > > > -obj-$(CONFIG_FBCON_MFB) += fbcon-mfb.o > > > # tristate ' Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16 > > FBCON_IPLAN2P16 can be deleted, since it doesn't exist. > > 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: James S. <jsi...@in...> - 2002-10-18 16:54:10
|
> It looks like that nobody is interested in VGA anymore. Are there > any objections against patch below? It is for current 2.5.42-bk, > and it fixes vga16fb compilability, and adds -depth 8 (to get 320x200, or > 360x480 in planar mode) and -depth 0 (to get fast textmode) to the vga16fb. I'm working on it. > If there are no objections, I'll split it up and send to Linus. But as Wait. I have your work already in the fbdev BK tree. I'm porting it to the new api. I just need to write up a fillrect and copy area function for vga planes mode. > I already said (and already asked), I'm not going to be vga16fb maintainer > (because of I use matroxfb everywhere), so if there is somebody else > who has vga16fb fixes, or who wants to maintain vga16fb, please step up... I guess I can do it. I need to rewrite vgacon in the near future anyways. |
|
From: James S. <jsi...@in...> - 2002-10-18 16:33:34
|
I'm working on it. I did some testing yesterday on the aty128 driver from Paul Mundt and Paul from samba.org. Give me a few a days. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net On Thu, 17 Oct 2002, Kyrian wrote: > Assuming this is a better place to post fbdev issues than the kernel devel > list (someone let me know if not please? and/or point me to a more > appropriate place to post?) > > Basically I still can't get the aty128fb.c driver to compile, for what still > look like API change reasons, even having downloaded the kernel from > BitKeeper again after receiving the below announcement from James... > > gcc -Wp,-MD,drivers/video/.aty128fb.o.d -D__KERNEL__ -Iinclude -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 > -march=k6 -Iarch/i386/mach-generic -nostdinc -iwithprefix include > -DKBUILD_BASENAME=aty128fb -c -o drivers/video/aty128fb.o > drivers/video/aty128fb.c > drivers/video/aty128fb.c:85:30: video/fbcon-cfb8.h: No such file or > directory > drivers/video/aty128fb.c:86:31: video/fbcon-cfb16.h: No such file or > directory > drivers/video/aty128fb.c:87:31: video/fbcon-cfb24.h: No such file or > directory > drivers/video/aty128fb.c:88:31: video/fbcon-cfb32.h: No such file or > directory > drivers/video/aty128fb.c:397: unknown field `fb_set_var' specified in > initializer > drivers/video/aty128fb.c:397: `gen_set_var' undeclared here (not in a > function) > drivers/video/aty128fb.c:397: initializer element is not constant > drivers/video/aty128fb.c:397: (near initialization for > `aty128fb_ops.fb_open') > drivers/video/aty128fb.c:400: unknown field `fb_get_cmap' specified in > initializer > drivers/video/aty128fb.c:400: `gen_get_cmap' undeclared here (not in a > function)drivers/video/aty128fb.c:400: initializer element is not constant > drivers/video/aty128fb.c:400: (near initialization for > `aty128fb_ops.fb_cursor')drivers/video/aty128fb.c:401: unknown field > `fb_set_cmap' specified in initializer > drivers/video/aty128fb.c:401: `gen_set_cmap' undeclared here (not in a > function)drivers/video/aty128fb.c:401: initializer element is not constant > drivers/video/aty128fb.c:401: (near initialization for > `aty128fb_ops.fb_setcolreg') > drivers/video/aty128fb.c:403: warning: initialization from incompatible > pointer > type > drivers/video/aty128fb.c:405: warning: initialization from incompatible > pointer > type > drivers/video/aty128fb.c: In function `aty128_init': > drivers/video/aty128fb.c:1510: structure has no member named `modename' > drivers/video/aty128fb.c:1513: structure has no member named `fontname' > drivers/video/aty128fb.c:1514: structure has no member named `changevar' > drivers/video/aty128fb.c:1515: structure has no member named `switch_con' > drivers/video/aty128fb.c:1515: `gen_switch' undeclared (first use in this > function) > drivers/video/aty128fb.c:1515: (Each undeclared identifier is reported only > oncedrivers/video/aty128fb.c:1515: for each function it appears in.) > drivers/video/aty128fb.c:1516: structure has no member named `updatevar' > drivers/video/aty128fb.c:1516: `gen_update_var' undeclared (first use in > this function) > drivers/video/aty128fb.c:1594: warning: implicit declaration of function > `gen_set_disp' > drivers/video/aty128fb.c:1597: warning: implicit declaration of function > `gen_set_var' > drivers/video/aty128fb.c: In function `aty128_pci_register': > drivers/video/aty128fb.c:1694: structure has no member named `disp' > drivers/video/aty128fb.c:1730: too many arguments to function > `aty128find_ROM' > drivers/video/aty128fb.c:1736: warning: passing arg 1 of > `aty128_get_pllinfo' from incompatible pointer type > drivers/video/aty128fb.c: At top level: > drivers/video/aty128fb.c:1402: warning: `aty128fb_rasterimg' defined but not > used > make[2]: *** [drivers/video/aty128fb.o] Error 1 > make[1]: *** [drivers/video] Error 2 > make: *** [drivers] Error 2 > [root@marius linux-20021017]# > > Err... help? > > Yours, > > Kev. > > > > Message: 17 > > Date: Thu, 17 Oct 2002 11:42:27 -0700 (PDT) > > From: James Simmons <jsi...@in...> > > To: Russell King <rm...@ar...> > > cc: Linux Fbdev development list > > <lin...@li...>, > > Linux Kernel Mailing List <lin...@vg...>, > > Linux console project <lin...@li...> > > Subject: Re: [Linux-fbdev-devel] Re: [ANNOUCE] fbdev changes finished. > > > > > > Give it a try. For people who want a diff it is avaiable at > > > > > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > > -- > Kev Green, aka Kyrian. Email: kyrian@ore.org Web: http://kyrian.ore.org/ > [ Looking for ISP contract work, CV at http://kyrian.ore.org/cv.html ] > "Be excellent to each other" -- Bill & Ted. > > > ------------------------------------------------------- > This sf.net email is sponsored by: viaVerio will pay you up to > $1,000 for every account that you consolidate with us. > http://ad.doubleclick.net/clk;4749864;7604308;v? > http://www.viaverio.com/consolidator/osdn.cfm > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
|
From: Kyrian <ky...@or...> - 2002-10-17 20:43:42
|
Assuming this is a better place to post fbdev issues than the kernel devel list (someone let me know if not please? and/or point me to a more appropriate place to post?) Basically I still can't get the aty128fb.c driver to compile, for what still look like API change reasons, even having downloaded the kernel from BitKeeper again after receiving the below announcement from James... gcc -Wp,-MD,drivers/video/.aty128fb.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -Iarch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=aty128fb -c -o drivers/video/aty128fb.o drivers/video/aty128fb.c drivers/video/aty128fb.c:85:30: video/fbcon-cfb8.h: No such file or directory drivers/video/aty128fb.c:86:31: video/fbcon-cfb16.h: No such file or directory drivers/video/aty128fb.c:87:31: video/fbcon-cfb24.h: No such file or directory drivers/video/aty128fb.c:88:31: video/fbcon-cfb32.h: No such file or directory drivers/video/aty128fb.c:397: unknown field `fb_set_var' specified in initializer drivers/video/aty128fb.c:397: `gen_set_var' undeclared here (not in a function) drivers/video/aty128fb.c:397: initializer element is not constant drivers/video/aty128fb.c:397: (near initialization for `aty128fb_ops.fb_open') drivers/video/aty128fb.c:400: unknown field `fb_get_cmap' specified in initializer drivers/video/aty128fb.c:400: `gen_get_cmap' undeclared here (not in a function)drivers/video/aty128fb.c:400: initializer element is not constant drivers/video/aty128fb.c:400: (near initialization for `aty128fb_ops.fb_cursor')drivers/video/aty128fb.c:401: unknown field `fb_set_cmap' specified in initializer drivers/video/aty128fb.c:401: `gen_set_cmap' undeclared here (not in a function)drivers/video/aty128fb.c:401: initializer element is not constant drivers/video/aty128fb.c:401: (near initialization for `aty128fb_ops.fb_setcolreg') drivers/video/aty128fb.c:403: warning: initialization from incompatible pointer type drivers/video/aty128fb.c:405: warning: initialization from incompatible pointer type drivers/video/aty128fb.c: In function `aty128_init': drivers/video/aty128fb.c:1510: structure has no member named `modename' drivers/video/aty128fb.c:1513: structure has no member named `fontname' drivers/video/aty128fb.c:1514: structure has no member named `changevar' drivers/video/aty128fb.c:1515: structure has no member named `switch_con' drivers/video/aty128fb.c:1515: `gen_switch' undeclared (first use in this function) drivers/video/aty128fb.c:1515: (Each undeclared identifier is reported only oncedrivers/video/aty128fb.c:1515: for each function it appears in.) drivers/video/aty128fb.c:1516: structure has no member named `updatevar' drivers/video/aty128fb.c:1516: `gen_update_var' undeclared (first use in this function) drivers/video/aty128fb.c:1594: warning: implicit declaration of function `gen_set_disp' drivers/video/aty128fb.c:1597: warning: implicit declaration of function `gen_set_var' drivers/video/aty128fb.c: In function `aty128_pci_register': drivers/video/aty128fb.c:1694: structure has no member named `disp' drivers/video/aty128fb.c:1730: too many arguments to function `aty128find_ROM' drivers/video/aty128fb.c:1736: warning: passing arg 1 of `aty128_get_pllinfo' from incompatible pointer type drivers/video/aty128fb.c: At top level: drivers/video/aty128fb.c:1402: warning: `aty128fb_rasterimg' defined but not used make[2]: *** [drivers/video/aty128fb.o] Error 1 make[1]: *** [drivers/video] Error 2 make: *** [drivers] Error 2 [root@marius linux-20021017]# Err... help? Yours, Kev. > Message: 17 > Date: Thu, 17 Oct 2002 11:42:27 -0700 (PDT) > From: James Simmons <jsi...@in...> > To: Russell King <rm...@ar...> > cc: Linux Fbdev development list > <lin...@li...>, > Linux Kernel Mailing List <lin...@vg...>, > Linux console project <lin...@li...> > Subject: Re: [Linux-fbdev-devel] Re: [ANNOUCE] fbdev changes finished. > > > > Give it a try. For people who want a diff it is avaiable at > > > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz -- Kev Green, aka Kyrian. Email: kyrian@ore.org Web: http://kyrian.ore.org/ [ Looking for ISP contract work, CV at http://kyrian.ore.org/cv.html ] "Be excellent to each other" -- Bill & Ted. |
|
From: James S. <jsi...@in...> - 2002-10-17 18:49:15
|
> > Give it a try. For people who want a diff it is avaiable at > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > ... which is not representative of the changes. > > Can you _please_ take much more care over patches and such like and take > the time to get them correct _please_. > > I really don't like patches that float around that unintentionally delete > other peoples drivers for no reason. Ugh!! I forgot to do a bk -r co -q on the fbdev BK respoitory before I made the diff. I will create a new diff and post it. I apologize for that. |
|
From: Russell K. <rm...@ar...> - 2002-10-17 17:28:11
|
On Thu, Oct 17, 2002 at 09:38:37AM -0700, James Simmons wrote: > I like to annouce that I just finished the final fbdev changes. They are > in the BK repository bk://fbdev.bkbits.net/fbdev-2.5. The changes are > > 1) Removal of all console related code in the lower level drivers. Smaller > easier to program drivers. > > 2) Now you can use the framebuffer driver WITHOUT framebuffer console. > Last night I built a kernel with MDA console and used the VESA > framebuffer by itself. Now you can easily debug new framebuffer > drivers. The real bonus is for embedded systems you have much smaller > kernels. > > 3) I moved the agp and drm code into drivers/video. I did NOT place any > drm code with framebuffer code at people's request. I simiple moved the > directory from one spot to another. The main reason I did this was > because some framebuffer drivers will need to use the agp code initialized > before the framebuffer layer. The DRM code was moved because it makes > sense to move it there. > > 4) I cleaned up the config.in for all the video stuff across all > platforms. > > You can grab the lastest BK tree at > > bk://fbdev.bkbits.net/fbdev-2.5 > > Give it a try. For people who want a diff it is avaiable at > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz ... which is not representative of the changes. Can you _please_ take much more care over patches and such like and take the time to get them correct _please_. I really don't like patches that float around that unintentionally delete other peoples drivers for no reason. -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
|
From: James S. <jsi...@in...> - 2002-10-17 16:45:13
|
Hi! I like to annouce that I just finished the final fbdev changes. They are in the BK repository bk://fbdev.bkbits.net/fbdev-2.5. The changes are 1) Removal of all console related code in the lower level drivers. Smaller easier to program drivers. 2) Now you can use the framebuffer driver WITHOUT framebuffer console. Last night I built a kernel with MDA console and used the VESA framebuffer by itself. Now you can easily debug new framebuffer drivers. The real bonus is for embedded systems you have much smaller kernels. 3) I moved the agp and drm code into drivers/video. I did NOT place any drm code with framebuffer code at people's request. I simiple moved the directory from one spot to another. The main reason I did this was because some framebuffer drivers will need to use the agp code initialized before the framebuffer layer. The DRM code was moved because it makes sense to move it there. 4) I cleaned up the config.in for all the video stuff across all platforms. You can grab the lastest BK tree at bk://fbdev.bkbits.net/fbdev-2.5 Give it a try. For people who want a diff it is avaiable at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note it is huge and against 2.5.43. The framebuffer console system is kind of flaky still since the api has changed alot. So alot of work will be done on fbcon.c from now on besides porting the drivers over. Have fun. CREDITS | 13 Documentation/DocBook/kernel-api.tmpl | 4 MAINTAINERS | 7 arch/alpha/config.in | 17 arch/arm/config.in | 10 arch/i386/config.in | 12 arch/i386/vmlinux.lds.s | 105 arch/ia64/config.in | 11 arch/m68k/config.in | 7 arch/mips/config.in | 11 arch/mips64/config.in | 15 arch/parisc/config.in | 19 arch/ppc/config.in | 7 arch/ppc64/config.in | 7 arch/sh/config.in | 13 arch/sparc/config.in | 7 arch/sparc64/config.in | 4 arch/x86_64/config.in | 12 drivers/Makefile | 3 drivers/char/Config.in | 202 drivers/char/Makefile | 2 drivers/char/agp/Config.help | 88 drivers/char/agp/Config.in | 22 drivers/char/agp/Makefile | 24 drivers/char/agp/agp.c | 1690 ---- drivers/char/agp/agp.h | 377 - drivers/char/agp/ali-agp.c | 265 drivers/char/agp/amd-agp.c | 408 - drivers/char/agp/frontend.c | 1086 -- drivers/char/agp/hp-agp.c | 394 - drivers/char/agp/i460-agp.c | 595 - drivers/char/agp/i810-agp.c | 594 - drivers/char/agp/i8x0-agp.c | 731 - drivers/char/agp/k8-agp.c | 476 - drivers/char/agp/sis-agp.c | 142 drivers/char/agp/sworks-agp.c | 626 - drivers/char/agp/via-agp.c | 151 drivers/char/drm/Config.help | 39 drivers/char/drm/Config.in | 17 drivers/char/drm/Makefile | 23 drivers/char/drm/README.drm | 46 drivers/char/drm/ati_pcigart.h | 203 drivers/char/drm/drm.h | 461 - drivers/char/drm/drmP.h | 908 -- drivers/char/drm/drm_agpsupport.h | 370 drivers/char/drm/drm_auth.h | 163 drivers/char/drm/drm_bufs.h | 1137 --- drivers/char/drm/drm_context.h | 781 -- drivers/char/drm/drm_dma.h | 657 - drivers/char/drm/drm_drawable.h | 51 drivers/char/drm/drm_drv.h | 1085 -- drivers/char/drm/drm_fops.h | 209 drivers/char/drm/drm_init.h | 116 drivers/char/drm/drm_ioctl.h | 249 drivers/char/drm/drm_lists.h | 230 drivers/char/drm/drm_lock.h | 251 drivers/char/drm/drm_memory.h | 467 - drivers/char/drm/drm_os_linux.h | 90 drivers/char/drm/drm_proc.h | 633 - drivers/char/drm/drm_scatter.h | 225 drivers/char/drm/drm_stub.h | 151 drivers/char/drm/drm_vm.h | 503 - drivers/char/drm/ffb.h | 15 drivers/char/drm/ffb_context.c | 539 - drivers/char/drm/ffb_drv.c | 401 - drivers/char/drm/ffb_drv.h | 276 drivers/char/drm/gamma.h | 148 drivers/char/drm/gamma_dma.c | 833 -- drivers/char/drm/gamma_drm.h | 89 drivers/char/drm/gamma_drv.c | 55 drivers/char/drm/gamma_drv.h | 120 drivers/char/drm/i810.h | 117 drivers/char/drm/i810_dma.c | 1253 --- drivers/char/drm/i810_drm.h | 248 drivers/char/drm/i810_drv.c | 56 drivers/char/drm/i810_drv.h | 207 drivers/char/drm/i830.h | 103 drivers/char/drm/i830_dma.c | 1291 --- drivers/char/drm/i830_drm.h | 251 drivers/char/drm/i830_drv.c | 58 drivers/char/drm/i830_drv.h | 216 drivers/char/drm/mga.h | 94 drivers/char/drm/mga_dma.c | 795 -- drivers/char/drm/mga_drm.h | 325 drivers/char/drm/mga_drv.c | 52 drivers/char/drm/mga_drv.h | 631 - drivers/char/drm/mga_state.c | 1077 -- drivers/char/drm/mga_ucode.h |11645 ------------------------------- drivers/char/drm/mga_warp.c | 212 drivers/char/drm/r128.h | 110 drivers/char/drm/r128_cce.c | 1010 -- drivers/char/drm/r128_drm.h | 308 drivers/char/drm/r128_drv.c | 55 drivers/char/drm/r128_drv.h | 504 - drivers/char/drm/r128_state.c | 1566 ---- drivers/char/drm/radeon.h | 154 drivers/char/drm/radeon_cp.c | 1648 ---- drivers/char/drm/radeon_drm.h | 563 - drivers/char/drm/radeon_drv.c | 53 drivers/char/drm/radeon_drv.h | 867 -- drivers/char/drm/radeon_irq.c | 256 drivers/char/drm/radeon_mem.c | 334 drivers/char/drm/radeon_state.c | 2190 ----- drivers/char/drm/sis.h | 81 drivers/char/drm/sis_drm.h | 46 drivers/char/drm/sis_drv.c | 49 drivers/char/drm/sis_drv.h | 45 drivers/char/drm/sis_ds.c | 406 - drivers/char/drm/sis_ds.h | 163 drivers/char/drm/sis_mm.c | 307 drivers/char/drm/tdfx.h | 42 drivers/char/drm/tdfx_drv.c | 92 drivers/video/Config.help | 149 drivers/video/Config.in | 457 - drivers/video/Makefile | 44 drivers/video/agp/Config.help | 88 drivers/video/agp/Config.in | 22 drivers/video/agp/Makefile | 24 drivers/video/agp/agp.c | 1690 ++++ drivers/video/agp/agp.h | 377 + drivers/video/agp/ali-agp.c | 265 drivers/video/agp/amd-agp.c | 408 + drivers/video/agp/frontend.c | 1086 ++ drivers/video/agp/hp-agp.c | 394 + drivers/video/agp/i460-agp.c | 595 + drivers/video/agp/i810-agp.c | 594 + drivers/video/agp/i8x0-agp.c | 731 + drivers/video/agp/k8-agp.c | 476 + drivers/video/agp/sis-agp.c | 142 drivers/video/agp/sworks-agp.c | 626 + drivers/video/agp/via-agp.c | 151 drivers/video/anakinfb.c | 117 drivers/video/aty/atyfb_base.c | 2711 ------- drivers/video/aty/mach64_ct.c | 2 drivers/video/aty/mach64_cursor.c | 2 drivers/video/aty/mach64_gx.c | 2 drivers/video/aty128fb.c | 3167 +++----- drivers/video/cfbcopyarea.c | 230 drivers/video/cfbfillrect.c | 107 drivers/video/cfbimgblt.c | 335 drivers/video/clps711xfb.c | 452 - drivers/video/console/Config.help | 149 drivers/video/console/dummycon.c | 74 drivers/video/console/fbcon-accel.c | 189 drivers/video/console/fbcon-accel.h | 34 drivers/video/console/fbcon-afb.c | 448 + drivers/video/console/fbcon-hga.c | 253 drivers/video/console/fbcon-ilbm.c | 296 drivers/video/console/fbcon-iplan2p2.c | 476 + drivers/video/console/fbcon-iplan2p4.c | 497 + drivers/video/console/fbcon-iplan2p8.c | 534 + drivers/video/console/fbcon-sti.c | 337 drivers/video/console/fbcon-vga-planes.c | 281 drivers/video/console/font_6x11.c | 3351 ++++++++ drivers/video/console/font_8x16.c | 4631 ++++++++++++ drivers/video/console/font_8x8.c | 2583 ++++++ drivers/video/console/font_acorn_8x8.c | 277 drivers/video/console/font_mini_4x6.c | 2158 +++++ drivers/video/console/font_pearl_8x8.c | 2587 ++++++ drivers/video/console/font_sun12x22.c | 6220 ++++++++++++++++ drivers/video/console/font_sun8x16.c | 275 drivers/video/console/fonts.c | 135 drivers/video/console/mdacon.c | 632 + drivers/video/console/newport_con.c | 746 + drivers/video/console/prom.uni | 11 drivers/video/console/promcon.c | 606 + drivers/video/console/sti-bmode.h | 287 drivers/video/console/sticon-bmode.c | 895 ++ drivers/video/console/sticon.c | 215 drivers/video/console/vgacon.c | 1062 ++ drivers/video/dnfb.c | 275 drivers/video/drm/Config.help | 39 drivers/video/drm/Config.in | 17 drivers/video/drm/Makefile | 23 drivers/video/drm/README.drm | 46 drivers/video/drm/ati_pcigart.h | 203 drivers/video/drm/drm.h | 461 + drivers/video/drm/drmP.h | 908 ++ drivers/video/drm/drm_agpsupport.h | 370 drivers/video/drm/drm_auth.h | 163 drivers/video/drm/drm_bufs.h | 1137 +++ drivers/video/drm/drm_context.h | 781 ++ drivers/video/drm/drm_dma.h | 657 + drivers/video/drm/drm_drawable.h | 51 drivers/video/drm/drm_drv.h | 1085 ++ drivers/video/drm/drm_fops.h | 209 drivers/video/drm/drm_init.h | 116 drivers/video/drm/drm_ioctl.h | 249 drivers/video/drm/drm_lists.h | 230 drivers/video/drm/drm_lock.h | 251 drivers/video/drm/drm_memory.h | 467 + drivers/video/drm/drm_os_linux.h | 90 drivers/video/drm/drm_proc.h | 633 + drivers/video/drm/drm_scatter.h | 225 drivers/video/drm/drm_stub.h | 151 drivers/video/drm/drm_vm.h | 503 + drivers/video/drm/ffb.h | 15 drivers/video/drm/ffb_context.c | 539 + drivers/video/drm/ffb_drv.c | 401 + drivers/video/drm/ffb_drv.h | 276 drivers/video/drm/gamma.h | 148 drivers/video/drm/gamma_dma.c | 833 ++ drivers/video/drm/gamma_drm.h | 89 drivers/video/drm/gamma_drv.c | 55 drivers/video/drm/gamma_drv.h | 120 drivers/video/drm/i810.h | 117 drivers/video/drm/i810_dma.c | 1253 +++ drivers/video/drm/i810_drm.h | 248 drivers/video/drm/i810_drv.c | 56 drivers/video/drm/i810_drv.h | 207 drivers/video/drm/i830.h | 103 drivers/video/drm/i830_dma.c | 1291 +++ drivers/video/drm/i830_drm.h | 251 drivers/video/drm/i830_drv.c | 58 drivers/video/drm/i830_drv.h | 216 drivers/video/drm/mga.h | 94 drivers/video/drm/mga_dma.c | 795 ++ drivers/video/drm/mga_drm.h | 325 drivers/video/drm/mga_drv.c | 52 drivers/video/drm/mga_drv.h | 631 + drivers/video/drm/mga_state.c | 1077 ++ drivers/video/drm/mga_ucode.h |11645 +++++++++++++++++++++++++++++++ drivers/video/drm/mga_warp.c | 212 drivers/video/drm/r128.h | 110 drivers/video/drm/r128_cce.c | 1010 ++ drivers/video/drm/r128_drm.h | 308 drivers/video/drm/r128_drv.c | 55 drivers/video/drm/r128_drv.h | 504 + drivers/video/drm/r128_state.c | 1566 ++++ drivers/video/drm/radeon.h | 154 drivers/video/drm/radeon_cp.c | 1648 ++++ drivers/video/drm/radeon_drm.h | 563 + drivers/video/drm/radeon_drv.c | 53 drivers/video/drm/radeon_drv.h | 867 ++ drivers/video/drm/radeon_irq.c | 256 drivers/video/drm/radeon_mem.c | 334 drivers/video/drm/radeon_state.c | 2190 +++++ drivers/video/drm/sis.h | 81 drivers/video/drm/sis_drm.h | 46 drivers/video/drm/sis_drv.c | 49 drivers/video/drm/sis_drv.h | 45 drivers/video/drm/sis_ds.c | 406 + drivers/video/drm/sis_ds.h | 163 drivers/video/drm/sis_mm.c | 307 drivers/video/drm/tdfx.h | 42 drivers/video/drm/tdfx_drv.c | 92 drivers/video/dummycon.c | 74 drivers/video/fbcmap.c | 57 drivers/video/fbcon-accel.c | 188 drivers/video/fbcon-accel.h | 34 drivers/video/fbcon-afb.c | 448 - drivers/video/fbcon-cfb16.c | 319 drivers/video/fbcon-cfb2.c | 225 drivers/video/fbcon-cfb24.c | 333 drivers/video/fbcon-cfb32.c | 305 drivers/video/fbcon-cfb4.c | 229 drivers/video/fbcon-cfb8.c | 294 drivers/video/fbcon-hga.c | 253 drivers/video/fbcon-ilbm.c | 296 drivers/video/fbcon-iplan2p2.c | 476 - drivers/video/fbcon-iplan2p4.c | 497 - drivers/video/fbcon-iplan2p8.c | 534 - drivers/video/fbcon-mfb.c | 217 drivers/video/fbcon-sti.c | 337 drivers/video/fbcon-vga-planes.c | 387 - drivers/video/fbcon.c | 2509 ------ drivers/video/fbgen.c | 217 drivers/video/fbmem.c | 961 -- drivers/video/fm2fb.c | 14 drivers/video/font_6x11.c | 3351 -------- drivers/video/font_8x16.c | 4631 ------------ drivers/video/font_8x8.c | 2583 ------ drivers/video/font_acorn_8x8.c | 277 drivers/video/font_mini_4x6.c | 2158 ----- drivers/video/font_pearl_8x8.c | 2587 ------ drivers/video/font_sun12x22.c | 6220 ---------------- drivers/video/font_sun8x16.c | 275 drivers/video/fonts.c | 135 drivers/video/g364fb.c | 268 drivers/video/hitfb.c | 14 drivers/video/hpfb.c | 15 drivers/video/macfb.c | 978 -- drivers/video/macmodes.c | 387 - drivers/video/maxinefb.c | 192 drivers/video/mdacon.c | 632 - drivers/video/modedb.c | 7 drivers/video/neofb.c | 25 drivers/video/newport_con.c | 746 - drivers/video/offb.c | 559 - drivers/video/pmag-ba-fb.c | 14 drivers/video/pmagb-b-fb.c | 14 drivers/video/prom.uni | 11 drivers/video/promcon.c | 606 - drivers/video/q40fb.c | 13 drivers/video/sa1100fb.c | 2 drivers/video/sgivwfb.c | 21 drivers/video/sis/Makefile | 2 drivers/video/sis/sis_accel.c | 495 + drivers/video/skeletonfb.c | 20 drivers/video/sti-bmode.h | 287 drivers/video/sticon-bmode.c | 895 -- drivers/video/sticon.c | 215 drivers/video/tdfxfb.c | 376 - drivers/video/tx3912fb.c | 13 drivers/video/vesafb.c | 386 - drivers/video/vfb.c | 17 drivers/video/vga16fb.c | 943 -- drivers/video/vgacon.c | 1055 -- include/linux/fb.h | 546 - include/linux/sisfb.h | 58 include/video/fbcon-cfb16.h | 34 include/video/fbcon-cfb2.h | 32 include/video/fbcon-cfb24.h | 34 include/video/fbcon-cfb32.h | 34 include/video/fbcon-cfb4.h | 32 include/video/fbcon-cfb8.h | 34 include/video/fbcon-mac.h | 32 include/video/fbcon-vga-planes.h | 1 include/video/fbcon.h | 795 -- 321 files changed, 82006 insertions(+), 96749 deletions(-) MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Geert U. <ge...@li...> - 2002-10-17 09:37:13
|
On 17 Oct 2002, Antonino Daplas wrote:
> - __u8 depth; /* Dpeth of the image */
> + __u8 depth; /* Dpeth of the image */
^^^^^
Please kill the spelling errors while re-indenting the code :-)
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: Antonino D. <ad...@po...> - 2002-10-17 00:23:04
|
On Mon, 2002-10-14 at 04:27, James Simmons wrote:
[...]
>
> /*
> * hardware cursor control
> */
>
> #define FB_CUR_SETCUR 0x01
> #define FB_CUR_SETPOS 0x02
> #define FB_CUR_SETHOT 0x04
> #define FB_CUR_SETCMAP 0x08
> #define FB_CUR_SETSHAPE 0x10
> #define FB_CUR_SETALL 0x1F
>
> struct fbcurpos {
> __u16 x, y;
> };
>
> struct fbcursor {
> __u16 set; /* what to set */
> __u16 enable; /* cursor on/off */
> struct fbcurpos pos; /* cursor position */
> struct fbcurpos hot; /* cursor hot spot */
> struct fb_cmap cmap; /* color map info */
> struct fbcurpos size; /* cursor bit map size */
> char *image; /* cursor image bits */
> char *mask; /* cursor mask bits */
> };
>
> If you have any suggestion please post you purpose struct. Thank you.
>
Hi James,
Since you seem to be very busy, here's an idea for the framebuffer
cursor API.
I have added a 'char *dest' entry to fbcursor which is basically a
bitmap of the current text underlying the cursor position. This should
make it easier for the software cursor to do the color inversion
manually. Also having 3 operands for the bit operation (source - image,
pattern - mask, destination - dest) should give more flexibility.
Additional fields are 'depth' - describes the color depth of the bitmap
- and 'rop' - the desired bit operation. The fields 'image', 'mask', and
'dest' should have the same depth and dimensions. I also removed
fb_cmap and instead used an array of pseudo_palette indices since all
the drawing functions rely on info->pseudo_palette for color
information.
fb_imageblit is used for drawing the software cursor instead of
fb_fillrect. This might be a bit faster because it does not have to
read the contents of the framebuffer as with fillrect using ROP_XOR.
It's also more flexible (ie, may draw a non-monochrome cursor image).
The flow is: fbcon_cursor -> display->dispsw->cursor ->
info->fbops->fb_cursor. Drivers can choose to create their own routines,
or use a generic one (gen_cursor) in fbgen.c. Drivers just need to
display and move the cursor. Flashing the cursor will be done by
fbcon. Thus, timer routines in the various drivers can be removed.
With the attached patch, the cursor should behave similarly to vgacon --
default cursor is underscore, but shape can be changed at will. Color
of the cursor will depend on the attribute of the underlying text. I'm
not sure if this is correct behavior though.
Patch is against 2.5.42.
Tony
diff -Naur linux-2.5.42/drivers/video/fbcon-accel.c linux/drivers/video/fbcon-accel.c
--- linux-2.5.42/drivers/video/fbcon-accel.c Wed Oct 16 23:35:27 2002
+++ linux/drivers/video/fbcon-accel.c Wed Oct 16 23:34:26 2002
@@ -146,6 +146,110 @@
}
}
+void fbcon_accel_cursor(struct display *p, int flags, int xx, int yy)
+{
+ static u32 palette_index[2];
+ static struct fb_index index = { 2, palette_index };
+ static char mask[64], image[64], *dest;
+ static int fgcolor, bgcolor, shape, width, height;
+ struct fb_info *info = p->fb_info;
+ struct fbcursor cursor;
+ int c;
+ char *font;
+
+ cursor.set = FB_CUR_SETPOS;
+ if (width != fontwidth(p) || height != fontheight(p)) {
+ width = fontwidth(p);
+ height = fontheight(p);
+ cursor.set |= FB_CUR_SETSIZE;
+ }
+
+ if ((p->conp->vc_cursor_type & 0x0f) != shape) {
+ shape = p->conp->vc_cursor_type & 0x0f;
+ cursor.set |= FB_CUR_SETSHAPE;
+ }
+
+ c = scr_readw((u16 *) p->cursor_pos);
+
+ if (fgcolor != (int) attr_fgcol(p, c) ||
+ bgcolor != (int) attr_bgcol(p, c)) {
+ fgcolor = (int) attr_fgcol(p, c);
+ bgcolor = (int) attr_bgcol(p, c);
+ cursor.set |= FB_CUR_SETCMAP;
+ }
+
+ c &= p->charmask;
+ font = p->fontdata + (c * ((width + 7)/8) * height);
+ if (font != dest) {
+ dest = font;
+ cursor.set |= FB_CUR_SETDEST;
+ }
+
+ if (flags & FB_CUR_SETCUR)
+ cursor.enable = 1;
+ else
+ cursor.enable = 0;
+
+ if (cursor.set & FB_CUR_SETCMAP) {
+ palette_index[0] = bgcolor;
+ palette_index[1] = fgcolor;
+ }
+
+ if (cursor.set & FB_CUR_SETSIZE) {
+ memset(image, 0xff, 64);
+ cursor.set |= FB_CUR_SETSHAPE;
+ }
+
+ if (cursor.set & FB_CUR_SETSHAPE) {
+ int w, cur_height, size, i = 0;
+
+
+ w = (width + 7)/8;
+
+ switch (shape) {
+ case CUR_NONE:
+ cur_height = 0;
+ break;
+ case CUR_UNDERLINE:
+ cur_height = (height < 10) ? 1 : 2;
+ break;
+ case CUR_LOWER_THIRD:
+ cur_height = height/3;
+ break;
+ case CUR_LOWER_HALF:
+ cur_height = height/2;
+ break;
+ case CUR_TWO_THIRDS:
+ cur_height = (height * 2)/3;
+ break;
+ case CUR_BLOCK:
+ default:
+ cur_height = height;
+ break;
+ }
+ size = (height - cur_height) * w;
+ while (size--)
+ mask[i++] = 0;
+ size = cur_height * w;
+ while(size--)
+ mask[i++] = 0xff;
+ }
+
+ cursor.size.x = width;
+ cursor.size.y = height;
+ cursor.pos.x = xx * width;
+ cursor.pos.y = yy * height;
+ cursor.image = image;
+ cursor.mask = mask;
+ cursor.dest = dest;
+ cursor.rop = ROP_XOR;
+ cursor.index = &index;
+ cursor.depth = 1;
+
+ if (info->fbops->fb_cursor)
+ info->fbops->fb_cursor(info, &cursor);
+}
+
/*
* `switch' for the low level operations
*/
@@ -158,6 +262,7 @@
.putcs = fbcon_accel_putcs,
.revc = fbcon_accel_revc,
.clear_margins =fbcon_accel_clear_margins,
+ .cursor = fbcon_accel_cursor,
.fontwidthmask =FONTWIDTHRANGE(1, 16)
};
diff -Naur linux-2.5.42/drivers/video/fbcon.c linux/drivers/video/fbcon.c
--- linux-2.5.42/drivers/video/fbcon.c Wed Oct 16 23:35:22 2002
+++ linux/drivers/video/fbcon.c Wed Oct 16 23:34:21 2002
@@ -722,10 +722,8 @@
"supported\n", info->fix.type, info->fix.type_aux,
p->var.bits_per_pixel);
p->dispsw->setup(p);
-
p->fgcol = p->var.bits_per_pixel > 2 ? 7 : (1<<p->var.bits_per_pixel)-1;
p->bgcol = 0;
-
if (!init) {
if (conp->vc_cols != nr_cols || conp->vc_rows != nr_rows)
vc_resize_con(nr_rows, nr_cols, con);
@@ -878,73 +876,69 @@
vbl_cursor_cnt = CURSOR_DRAW_DELAY;
}
-
static void fbcon_cursor(struct vc_data *conp, int mode)
{
- int unit = conp->vc_num;
- struct display *p = &fb_display[unit];
- int y = conp->vc_y;
-
- if (mode & CM_SOFTBACK) {
- mode &= ~CM_SOFTBACK;
- if (softback_lines) {
- if (y + softback_lines >= conp->vc_rows)
- mode = CM_ERASE;
- else
- y += softback_lines;
- }
- } else if (softback_lines)
- fbcon_set_origin(conp);
-
- /* do we have a hardware cursor ? */
- if (p->dispsw->cursor) {
+ int unit = conp->vc_num;
+ struct display *p = &fb_display[unit];
+ int y = conp->vc_y;
+
+ if (mode & CM_SOFTBACK) {
+ mode &= ~CM_SOFTBACK;
+ if (softback_lines) {
+ if (y + softback_lines >= conp->vc_rows)
+ mode = CM_ERASE;
+ else
+ y += softback_lines;
+ }
+ } else if (softback_lines)
+ fbcon_set_origin(conp);
+
+ /* Avoid flickering if there's no real change. */
+ if (p->cursor_x == conp->vc_x && p->cursor_y == y &&
+ (mode == CM_ERASE) == !cursor_on)
+ return;
+
+ cursor_on = 0;
+ if (cursor_drawn)
+ p->dispsw->cursor(p, 0, p->cursor_x, real_y(p, p->cursor_y));
+
p->cursor_x = conp->vc_x;
p->cursor_y = y;
- p->dispsw->cursor(p, mode, p->cursor_x, real_y(p, p->cursor_y));
- return;
- }
+ p->cursor_pos = conp->vc_pos;
- /* Avoid flickering if there's no real change. */
- if (p->cursor_x == conp->vc_x && p->cursor_y == y &&
- (mode == CM_ERASE) == !cursor_on)
- return;
-
- cursor_on = 0;
- if (cursor_drawn)
- p->dispsw->revc(p, p->cursor_x, real_y(p, p->cursor_y));
-
- p->cursor_x = conp->vc_x;
- p->cursor_y = y;
-
- switch (mode) {
+ switch (mode) {
case CM_ERASE:
- cursor_drawn = 0;
- break;
+ cursor_drawn = 0;
+ break;
case CM_MOVE:
case CM_DRAW:
- if (cursor_drawn)
- p->dispsw->revc(p, p->cursor_x, real_y(p, p->cursor_y));
- vbl_cursor_cnt = CURSOR_DRAW_DELAY;
- cursor_on = 1;
- break;
+ if (cursor_drawn)
+ p->dispsw->cursor(p, FB_CUR_SETCUR, p->cursor_x, real_y(p, p->cursor_y));
+ vbl_cursor_cnt = CURSOR_DRAW_DELAY;
+ cursor_on = 1;
+ break;
}
+
}
-
static void fbcon_vbl_handler(int irq, void *dummy, struct pt_regs *fp)
{
- struct display *p;
-
- if (!cursor_on)
- return;
-
- if (vbl_cursor_cnt && --vbl_cursor_cnt == 0) {
- p = &fb_display[fg_console];
- if (p->dispsw->revc)
- p->dispsw->revc(p, p->cursor_x, real_y(p, p->cursor_y));
- cursor_drawn ^= 1;
- vbl_cursor_cnt = cursor_blink_rate;
- }
+ struct display *p;
+
+ if (!cursor_on)
+ return;
+
+ if (vbl_cursor_cnt && --vbl_cursor_cnt == 0) {
+ int flag;
+
+ p = &fb_display[fg_console];
+ flag = 0;
+ if (!cursor_drawn)
+ flag = FB_CUR_SETCUR;
+ p->dispsw->cursor(p, flag, p->cursor_x, real_y(p, p->cursor_y));
+ cursor_drawn ^= 1;
+ vbl_cursor_cnt = cursor_blink_rate;
+ }
}
static int scrollback_phys_max = 0;
diff -Naur linux-2.5.42/drivers/video/fbgen.c linux/drivers/video/fbgen.c
--- linux-2.5.42/drivers/video/fbgen.c Wed Oct 16 23:35:18 2002
+++ linux/drivers/video/fbgen.c Wed Oct 16 23:34:30 2002
@@ -272,11 +272,54 @@
return 0;
}
+/*
+ * Supports monochrome cursor only
+ */
+void gen_cursor(struct fb_info *info, struct fbcursor *cursor)
+{
+ struct fb_image image;
+ static char data[64];
+ int size = ((cursor->size.x + 7)/8) * cursor->size.y;
+ int i;
+
+ if (cursor->depth == 1) {
+ image.bg_color = cursor->index->entry[0];
+ image.fg_color = cursor->index->entry[1];
+
+ if (cursor->enable) {
+ switch (cursor->rop) {
+ case ROP_XOR:
+ for (i = 0; i < size; i++)
+ data[i] = (cursor->image[i] & cursor->mask[i]) ^ cursor->dest[i];
+ break;
+ case ROP_COPY:
+ default:
+ for (i = 0; i < size; i++)
+ data[i] = cursor->image[i] & cursor->mask[i];
+ break;
+ }
+ }
+ else
+ memcpy(data, cursor->dest, size);
+
+ image.dx = cursor->pos.x;
+ image.dy = cursor->pos.y;
+ image.width = cursor->size.x;
+ image.height = cursor->size.y;
+ image.depth = cursor->depth;
+ image.data = data;
+
+ if (info->fbops->fb_imageblit)
+ info->fbops->fb_imageblit(info, &image);
+ }
+}
+
/* generic frame buffer operations */
EXPORT_SYMBOL(gen_set_var);
EXPORT_SYMBOL(gen_get_cmap);
EXPORT_SYMBOL(gen_set_cmap);
EXPORT_SYMBOL(fbgen_pan_display);
+EXPORT_SYMBOL(gen_cursor);
/* helper functions */
EXPORT_SYMBOL(do_install_cmap);
EXPORT_SYMBOL(gen_update_var);
diff -Naur linux-2.5.42/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.42/include/linux/fb.h Wed Oct 16 23:35:48 2002
+++ linux/include/linux/fb.h Wed Oct 16 23:40:44 2002
@@ -220,6 +220,11 @@
__u16 *transp; /* transparency, can be NULL */
};
+struct fb_index {
+ __u32 len; /* number of entries */
+ __u32 *entry; /* "pseudopalette" color index entries */
+};
+
struct fb_con2fbmap {
__u32 console;
__u32 framebuffer;
@@ -280,14 +285,45 @@
};
struct fb_image {
- __u32 width; /* Size of image */
+ __u32 width; /* Size of image */
__u32 height;
- __u16 dx; /* Where to place image */
- __u16 dy;
- __u32 fg_color; /* Only used when a mono bitmap */
+ __u32 dx; /* Where to place image */
+ __u32 dy;
+ __u32 fg_color; /* Only used when a mono bitmap */
__u32 bg_color;
- __u8 depth; /* Dpeth of the image */
- char *data; /* Pointer to image data */
+ __u8 depth; /* Dpeth of the image */
+ char *data; /* Pointer to image data */
+};
+
+/*
+ * hardware cursor control
+ */
+
+#define FB_CUR_SETCUR 0x01
+#define FB_CUR_SETPOS 0x02
+#define FB_CUR_SETHOT 0x04
+#define FB_CUR_SETCMAP 0x08
+#define FB_CUR_SETSHAPE 0x10
+#define FB_CUR_SETDEST 0x20
+#define FB_CUR_SETSIZE 0x40
+#define FB_CUR_SETALL 0xFF
+
+struct fbcurpos {
+ __u32 x, y;
+};
+
+struct fbcursor {
+ __u32 set; /* what to set */
+ __u32 enable; /* cursor on/off */
+ __u32 rop; /* bitop operation */
+ __u8 depth; /* color depth of image */
+ struct fbcurpos pos; /* cursor position */
+ struct fbcurpos hot; /* cursor hot spot */
+ struct fb_index *index; /* color map info */
+ struct fbcurpos size; /* cursor bit map size */
+ char *image; /* cursor image bits */
+ char *mask; /* cursor mask bits */
+ char *dest; /* destination */
};
#ifdef __KERNEL__
@@ -342,6 +378,8 @@
void (*fb_copyarea)(struct fb_info *info, struct fb_copyarea *region);
/* Draws a image to the display */
void (*fb_imageblit)(struct fb_info *info, struct fb_image *image);
+ /* Draws cursor */
+ void (*fb_cursor)(struct fb_info *info, struct fbcursor *cursor);
/* perform polling on fb device */
int (*fb_poll)(struct fb_info *info, poll_table *wait);
/* perform fb specific ioctl (optional) */
@@ -351,6 +389,7 @@
int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
/* switch to/from raster image mode */
int (*fb_rasterimg)(struct fb_info *info, int start);
+
};
struct fb_info {
@@ -399,12 +438,12 @@
struct fb_info *info);
extern int gen_set_cmap(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info);
+extern void gen_cursor(struct fb_info *info, struct fbcursor *cursor);
extern int fb_pan_display(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
extern void cfb_fillrect(struct fb_info *info, struct fb_fillrect *rect);
extern void cfb_copyarea(struct fb_info *info, struct fb_copyarea *region);
extern void cfb_imageblit(struct fb_info *info, struct fb_image *image);
-
/*
* Helper functions
*/
diff -Naur linux-2.5.42/include/video/fbcon.h linux/include/video/fbcon.h
--- linux-2.5.42/include/video/fbcon.h Wed Oct 16 23:35:39 2002
+++ linux/include/video/fbcon.h Wed Oct 16 23:34:49 2002
@@ -35,7 +35,7 @@
void (*putcs)(struct vc_data *conp, struct display *p, const unsigned short *s,
int count, int yy, int xx);
void (*revc)(struct display *p, int xx, int yy);
- void (*cursor)(struct display *p, int mode, int xx, int yy);
+ void (*cursor)(struct display *p, int flags, int xx, int yy);
int (*set_font)(struct display *p, int width, int height);
void (*clear_margins)(struct vc_data *conp, struct display *p,
int bottom_only);
@@ -72,6 +72,7 @@
int vrows; /* number of virtual rows */
unsigned short cursor_x; /* current cursor position */
unsigned short cursor_y;
+ unsigned long cursor_pos;
int fgcol; /* text colors */
int bgcol;
u_long next_line; /* offset to one line below */
|
|
From: Michel <mi...@da...> - 2002-10-16 22:45:47
|
On Mit, 2002-10-16 at 22:55, Nicholas Wourms wrote: >=20 > A) Is it (or will it ever be) possible to run dual head=20 > using two different cards (like radeon & riva-tnt2)? I know=20 > there is still much work to be done, but I was curious if=20 > this was even remotely possible. I think it should theoretically work, but as always the only way to tell is to try it. :) > B) Does anyone have a painless, yet precise way of=20 > generating modelines for fb.modes if you are using=20 > XFree-4.2? I only ask because the XFree modelines are all=20 > determined by i2c DDC probing, thus there are none in the=20 > XF86Config file. If the X driver supports Option "UseFBDev", you should be able to use fbset with that. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Nicholas W. <nw...@ne...> - 2002-10-16 20:58:52
|
Benjamin Herrenschmidt wrote: >>I was curious to know if the maintainer for the radeonfb >>driver was planning to update it wrt James' recent API >>changes. Considiering it is the latest line available, I'd >>hope that its brokeness will not be permanent ;-). > > > I've ported radeonfb 0.1.6 to 2.5.42 (available in the linuxppc-2.5 > bk tree) and will port it to James latest changes. Ani (the > maintainer) will probably then just use that port. > > Ben. > Excellent! Two other questions (not necessarily related): A) Is it (or will it ever be) possible to run dual head using two different cards (like radeon & riva-tnt2)? I know there is still much work to be done, but I was curious if this was even remotely possible. Sorta hate to let a good video card go to waste if you know what I mean :-). B) Does anyone have a painless, yet precise way of generating modelines for fb.modes if you are using XFree-4.2? I only ask because the XFree modelines are all determined by i2c DDC probing, thus there are none in the XF86Config file. The modeline output captured in the log XFree.0.log is not the same output which modeline2fb expects. Anyhow, I've tried using some of the information in the log, but I always get funky results. I may be looking in the wrong place, but the documentation for both the fbdev kernel drivers and the X drivers are sorely out of date, so please excuse me if this is a question that has previously been answered. I just need some formulae to convert values between what shows up in XFree.0.log when i2c DDC probes for the modelines and what needs to go in fb.modes. Thanks in advance! Cheers, Nicholas |
|
From: Benjamin H. <be...@ke...> - 2002-10-16 20:30:37
|
>I was curious to know if the maintainer for the radeonfb >driver was planning to update it wrt James' recent API >changes. Considiering it is the latest line available, I'd >hope that its brokeness will not be permanent ;-). I've ported radeonfb 0.1.6 to 2.5.42 (available in the linuxppc-2.5 bk tree) and will port it to James latest changes. Ani (the maintainer) will probably then just use that port. Ben. |
|
From: <sy...@sc...> - 2002-10-16 18:40:38
|
On Wed, Oct 16, 2002 at 04:25:20PM +0200, Petr Vandrovec wrote: > On G450/G550 I use frequency specified in BIOS PINS. G400 (and older) > historically used hardwired values in matroxfb, and because of I do not > use them regulary anymore, I try to not touch their initialization code Ok that clears it up. I have a G400. > If you'll cook and test patch which will set system clocks on G400 > according to the value specified in the BIOS, or if you'll create > patch which will add ioctl() or some other operation to set system > PLL, I'll apply it without problem (if code is correct, changing > system PLL is not trivial operation). Maybe I'll try something if/when I have too much time on my hands. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: <sy...@sc...> - 2002-10-16 18:27:42
|
On Wed, Oct 16, 2002 at 08:19:10PM +0200, Petr Vandrovec wrote: > > You mean the patch that gives the problem or .. what? It's the > > vsync-irq-patch on your ftp server. > > Hm... > > platan:~# cd ~ftp > platan:/home/ftp# find -name '*irq*' > platan:/home/ftp# > > so I have to ask stupid question... where is my ftp server? I'd say it's probably from DirectFB. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: Petr V. <VAN...@vc...> - 2002-10-16 18:19:41
|
On 16 Oct 02 at 18:53, Javier Marcet wrote:
> >> One strange thing I've seen though, is that I cannot use 'fbset -depth
> >> xx' with xx other than 32 or I'll get:
> >> 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'
>
> >16bpp should work too on second head.
>
> I can only use 32 bits. Don't ask me why.
Do you have compiled 16bpp into kernel? And if everything else
fails, what does '-depth 16 -rgba 5,6,5' or '-depth 16 -rgba 5,5,5,1'?
> >Maybe that it enables IRQ on card before installing IRQ handler.
> >In such case nobody is going to clear IRQ in mga IRQ status register,
> >and your system is processing endless stream of interrupts. Buying
> >another CPU may give you chance to debug it. Or if you'll send
> >me pointer to the patch, I can review it...
>
> You mean the patch that gives the problem or .. what? It's the
> vsync-irq-patch on your ftp server.
Hm...
platan:~# cd ~ftp
platan:/home/ftp# find -name '*irq*'
platan:/home/ftp#
so I have to ask stupid question... where is my ftp server?
> >If mga-*-tvout, it adds support for DVI-D and TV outputs available
> >on G450/G550.
>
> OK, I don't need that one but it's already included in -ac branch.
> Maybe Alan agrees to include the fbset-through-vt one too, even if
> Marcelo, or whoever, refused to include it.
mga-*-tvout allows 'v4lctl -c /dev/fb0 xxxx' to set brightness/contrast
on TV output. I'm not sure whether Alan merged this too or not,
as it uses v4l2 interface, which is not in the kernel yet (and as it
stands, v4l2 is not going to 2.6.x too).
> >Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt
> >also on newer hardware.
>
> Tell me if you wanna have results from other systems.
I'll try to create some selfcontained benchmark.
> 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at de800000 (32-bit, non-prefetchable) [size=512]
>
> 00:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> Subsystem: Unknown device 0030:13eb
> Flags: bus master, medium devsel, latency 32, IRQ 11
> Memory at e1000000 (32-bit, prefetchable) [size=4K]
> Capabilities: [04] #06 [0290]
>
> 00:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> Subsystem: Unknown device 0030:13eb
> Flags: bus master, medium devsel, latency 32, IRQ 11
> Memory at e0800000 (32-bit, prefetchable) [size=4K]
> Capabilities: [04] #06 [0290]
>
> Whereas if I remove the DVB card, the output is:
>
> 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> Subsystem: Hauppauge computer works Inc. WinTV/GO
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at e1000000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
>
> 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> Subsystem: Hauppauge computer works Inc. WinTV/GO
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at e0800000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
I know that you'll not believe me, but your DVB card has hardware
problem: it grounds pin DATA6 of PCI bus to zero: so it gets 04 instead
of 44 from capabilities, 0030 instead 0070 from subsystem vendor
ID...
I cannot explain why busid changed for your Bt878: if it would move
from 0A to 02, or disappeared completely, I could understand it...
but move from 0A to 0C? Sorry...
Petr
|
754 messages has been excluded from this view by a project administrator.
