From: David Eger <hidden> Date: 2004-05-12 23:41:25
I fleshed out Geert's idea from the last radeonfb thread on bringing
fbcon's interaction with the underlying framebuffer drivers up-to-date.
Now fbcon should be smart and actually *use* fb-driver provided accel
functions ;-)
Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
should serve as the way framebuffers pass hints to higher layers.
This should totally obsolete the accel_flags in var (which till now has
had one half-heartedly used value FB_ACCELF_TEXT).
The patches that follow are:
1) my radeonfb copyarea() fix. this is already in -mm.
2) James's fbcon init cleanup, modified for benh's tree.
3) my fb-accel-capabilities patch
When I boot with this, I have a nice accelerated framebuffer, huzzah.
This *shouldn't* break anyone's setup. Please, test this patch!
Look good? Comments?
Still not done:
- get rid of old comments in include/linux/fb.h
- get rid of all old references to useless var.accel_flags
- update other drivers to indicate if they have fast accel() funcs
-dte
---
getting bounce messages from me? let me know and you'll go on my whitelist
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
@@ -2235,33 +2237,21 @@return0;}-staticvoidfbcon_suspended(structfb_info*info)+staticvoidfbcon_suspended(structfb_info*info,structvc_data*vc){/* Clear cursor, restore saved data */-info->cursor.enable=0;-info->fbops->fb_cursor(info,&info->cursor);+fbcon_cursor(vc,CM_ERASE);}-staticvoidfbcon_resumed(structfb_info*info)+staticvoidfbcon_resumed(structfb_info*info,structvc_data*vc){-structvc_data*vc;--if(info->currcon<0)-return;-vc=vc_cons[info->currcon].d;-update_screen(vc->vc_num);}-staticvoidfbcon_mode_changed(structfb_info*info)+staticvoidfbcon_mode_changed(structfb_info*info,structvc_data*vc){-structvc_data*vc;introws,cols;-if(info->currcon<0)-return;-vc=vc_cons[info->currcon].d;-/* This isn't perfect yet. If we change one console, we*don'tchangethemallandweswitchbacktothewrong*modeonnextconsoleswitch.Weneedtoeitherkeepa
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
@@ -607,8 +607,10 @@/* on which frame buffer will we open this console? */info=registered_fb[(int)con2fb_map[unit]];-if(info->var.accel_flags)-fb_display[unit].scrollmode=SCROLL_YNOMOVE;+if(info->fix.hwaccel&FB_HWACCEL_COPYAREA)+fb_display[unit].scrollmode=SCROLL_YACCEL;+elseif(info->var.accel_flags)+fb_display[unit].scrollmode=SCROLL_YPANWRAP;elsefb_display[unit].scrollmode=SCROLL_YREDRAW;fbcon_set_display(vc,init,!init);
@@ -624,20 +626,23 @@static__inline__voidupdatescrollmode(structdisplay*p,structvc_data*vc){structfb_info*info=registered_fb[(int)con2fb_map[vc->vc_num]];-intm;-if(p->scrollmode&__SCROLL_YFIXED)-return;++switch(p->scrollmode&__SCROLL_YMASK){+case__SCROLL_YACCEL:+case__SCROLL_YREDRAW:+return;+}++/* assume we should do wrap/pan if we can */if(divides(info->fix.ywrapstep,vc->vc_font.height)&&-divides(vc->vc_font.height,info->var.yres_virtual))+divides(vc->vc_font.height,info->var.yres_virtual))m=__SCROLL_YWRAP;elseif(divides(info->fix.ypanstep,vc->vc_font.height)&&info->var.yres_virtual>=info->var.yres+vc->vc_font.height)m=__SCROLL_YPAN;-elseif(p->scrollmode&__SCROLL_YNOMOVE)+elsem=__SCROLL_YREDRAW;-else-m=__SCROLL_YMOVE;p->scrollmode=(p->scrollmode&~__SCROLL_YMASK)|m;}
@@ -92,8 +90,9 @@witheverylinecoveringallscreencolumns,itwouldnotbetherightbenchmark).*/-#define SCROLL_YREDRAW (__SCROLL_YFIXED|__SCROLL_YREDRAW)-#define SCROLL_YNOMOVE (__SCROLL_YNOMOVE|__SCROLL_YPANREDRAW)+#define SCROLL_YACCEL (__SCROLL_YACCEL)+#define SCROLL_YPANWRAP (__SCROLL_YPANREDRAW)+#define SCROLL_YREDRAW (__SCROLL_YREDRAW)/* SCROLL_YNOPARTIAL, used in combination with the above, is for videocardswhichcannothandleusingpanningtoscrollaportionofthe
@@ -125,8 +128,10 @@unsignedlongmmio_start;/* Start of Memory Mapped I/O *//* (physical address) */__u32mmio_len;/* Length of Memory Mapped I/O */-__u32accel;/* Type of acceleration available */-__u16reserved[3];/* Reserved for future compatibility */+__u32accel;/* Indicate to driver which */+/* specific chip/card we have */+__u16hwaccel;/* Which accel ops are hw-supported? */+__u16reserved[2];/* Reserved for future compatibility */};/* Interpretation of offset for color fields: All offsets are from the right,-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
I fleshed out Geert's idea from the last radeonfb thread on bringing
fbcon's interaction with the underlying framebuffer drivers up-to-date.
Now fbcon should be smart and actually *use* fb-driver provided accel
functions ;-)
Nice!
Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
should serve as the way framebuffers pass hints to higher layers.
I think we agreed to put it in fb_info instead, since it doesn't really matter
for user space.
This should totally obsolete the accel_flags in var (which till now has
had one half-heartedly used value FB_ACCELF_TEXT).
Well, we still need a way to know when the fbdev has to reinitialize its accel
engine, when switching the console from graphics mode (user space does accel)
to text mode (kernel uses accel). Currently this is done when FB_ACCELF_TEXT is
set.
BTW, we've been talking about allowing kernel messages (mainly oops and panic)
to show up under X. Since we cannot use the accel engine for that, perhaps we
need different routines for fb_{fillrect,copyarea,imageblit}() for the
accelerated vs. non-accelerated cases? And fbcon could compare the function
pointers, instead of looking at .hwaccel.
(Yes, I know it's still possible to lock up your card when using unaccelerated
drawing while an accelerated operation is in progress on some cards).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
From: David Eger <hidden> Date: 2004-05-13 11:34:36
I guess I needed a few more flags for hwaccel ;-)
And I guess there will be more than three patches in this series... ;-)
-dte
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/13 13:25:46+02:00 eger@rosencrantz.theboonies.us
# update fb.h with some new flags needed during ATI upgrade
# to new fix.hwaccel semantics
#
# include/linux/fb.h
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +4 -2
# added some FB_HWACCEL_ flags: DISABLED, IMAGEBLIT
# marked var.accel_flags obsolete
#
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h Thu May 13 13:28:07 2004+++ b/include/linux/fb.h Thu May 13 13:28:07 2004
@@ -160,7 +162,7 @@#define FB_ACTIVATE_ALL 64 /* change all VCs on this fb */#define FB_ACTIVATE_FORCE 128 /* force apply even when no change*/-#define FB_ACCELF_TEXT 1 /* text mode acceleration */+#define FB_ACCELF_TEXT 1 /* text mode acceleration (OBSOLETE) */#define FB_SYNC_HOR_HIGH_ACT 1 /* horizontal sync high active */#define FB_SYNC_VERT_HIGH_ACT 2 /* vertical sync high active */
@@ -206,7 +208,7 @@__u32height;/* height of picture in mm */__u32width;/* width of picture in mm */-__u32accel_flags;/* acceleration flags (hints) */+__u32accel_flags;/* (OBSOLETE) see fix.hwaccel *//* Timing: All values in pixclocks, except pixclock (of course) */__u32pixclock;/* pixel clock in ps (pico seconds) */-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
@@ -1224,7 +1222,7 @@FB_VISUAL_PSEUDOCOLOR:FB_VISUAL_DIRECTCOLOR;/* Initialize the graphics engine */-if(par->accel_flags&FB_ACCELF_TEXT)+if(info->fix.hwaccel!=FB_HWACCEL_DISABLED)aty_init_engine(par,info);#ifdef CONFIG_BOOTX_TEXT
@@ -1304,11 +1302,6 @@returnerr;}-if(var->accel_flags&FB_ACCELF_TEXT)-info->var.accel_flags=FB_ACCELF_TEXT;-else-info->var.accel_flags=0;-#if 0 /* fbmon is not done. uncomment for 2.5.x -brad */if(!fbmon_valid_timings(pixclock,htotal,vtotal,info))return-EINVAL;
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
From: David Eger <hidden> Date: 2004-05-13 12:26:50
Quoting Geert Uytterhoeven [off-list ref]:
quoted
Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
should serve as the way framebuffers pass hints to higher layers.
I think we agreed to put it in fb_info instead, since it doesn't really
matter for user space.
It doesn't so much matter to me. I just saw some built-in padding in
fb_fix_screeninfo I could steal..
quoted
This should totally obsolete the accel_flags in var (which till now has
had one half-heartedly used value FB_ACCELF_TEXT).
Well, we still need a way to know when the fbdev has to reinitialize its
accel engine, when switching the console from graphics mode (user space
does accel) to text mode (kernel uses accel). Currently this is done when
FB_ACCELF_TEXT is set.
thought this was changed to KD_GRAPHICS and KD_TEXT...
BTW, we've been talking about allowing kernel messages (mainly oops and
panic) to show up under X. Since we cannot use the accel engine for that,
perhaps we need different routines for fb_{fillrect,copyarea,imageblit}()
for the accelerated vs. non-accelerated cases? And fbcon could compare
the function pointers, instead of looking at .hwaccel.
If we want the console to display an oops under X then the drawing functions
need to be smart enough to grok the current mode/state of the accel engine and
not rely on var. Is that what we want?
Comparing pointers just won't work, though. For example, the radeon driver
decides whether to call the cfb_fillrect() functions or do real hw accel from
within radeonfb_fillrect().
-dte
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-13 22:55:36
Well, we still need a way to know when the fbdev has to reinitialize its accel
engine, when switching the console from graphics mode (user space does accel)
to text mode (kernel uses accel). Currently this is done when FB_ACCELF_TEXT is
set.
Current fbcon should do a set_var with FB_ACTIVATE_FORCE (thus forcing a
call to set_par) when switching from KD_TEXT to KD_GRAPHICS
BTW, we've been talking about allowing kernel messages (mainly oops and panic)
to show up under X. Since we cannot use the accel engine for that, perhaps we
need different routines for fb_{fillrect,copyarea,imageblit}() for the
accelerated vs. non-accelerated cases? And fbcon could compare the function
pointers, instead of looking at .hwaccel.
(Yes, I know it's still possible to lock up your card when using unaccelerated
drawing while an accelerated operation is in progress on some cards).
Comparing function pointers ? That's evil ;)
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click