* RFC: vesafb
@ 2002-01-23 19:20 hollis
2002-01-24 4:42 ` Michel Lanners
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: hollis @ 2002-01-23 19:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sdi
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
The attached patch allows vesafb to work on PPC. vesafb does surprisingly
little with the BIOS (which I thought was the whole point of VESA). With some
ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
the card, and the driver just uses it and never mucks with it.
This patch allows me to get an 800x600x8 console on the Thinkpad 850, and
640x480x8 on the Carolina machines. More interestingly it allows X to work on
the Thinkpad, which currently doesn't work and has never worked in >16 colors.
It should also work on the 7020 (Sven?), which uses the Weitek 9100 card and
currently is driverless.
This patch is only for PReP, which is probably the only place it's really
useful (since CHRP and PMac have offb), but would be easy enough to add to.
Comments?
-Hollis
[-- Attachment #2: vesafb-ppc.diff --]
[-- Type: text/plain, Size: 6061 bytes --]
===== drivers/video/Config.in 1.12 vs edited =====
--- 1.12/drivers/video/Config.in Thu Dec 6 11:36:15 2001
+++ edited/drivers/video/Config.in Tue Jan 22 11:16:00 2002
@@ -73,6 +73,7 @@
bool ' Chips 65550 display support' CONFIG_FB_CT65550
bool ' IMS Twin Turbo display support' CONFIG_FB_IMSTT
dep_bool ' S3 Trio display support' CONFIG_FB_S3TRIO $CONFIG_ALL_PPC
+ bool ' VESA VGA graphics console' CONFIG_FB_VESA
tristate ' VGA 16-color graphics console' CONFIG_FB_VGA16
if [ "$CONFIG_8xx" = "y" ]; then
dep_tristate ' RPX LCD display support' CONFIG_FB_RPX $CONFIG_RPXLITE
===== drivers/video/vesafb.c 1.6 vs edited =====
--- 1.6/drivers/video/vesafb.c Fri Nov 16 14:45:58 2001
+++ edited/drivers/video/vesafb.c Tue Jan 22 15:14:35 2002
@@ -23,7 +23,9 @@
#include <linux/init.h>
#include <asm/io.h>
-#include <asm/mtrr.h>
+#ifdef __i386__
+# include <asm/mtrr.h>
+#endif /* __i386__ */
#include <video/fbcon.h>
#include <video/fbcon-cfb8.h>
@@ -109,6 +111,7 @@
static int vesafb_pan_display(struct fb_var_screeninfo *var, int con,
struct fb_info *info)
{
+#ifdef __i386__
int offset;
if (!ypan)
@@ -131,6 +134,9 @@
"d" (offset >> 16), /* EDX */
"D" (&pmi_start)); /* EDI */
return 0;
+#else
+ return -EINVAL;
+#endif
}
static int vesafb_update_var(int con, struct fb_info *info)
@@ -304,11 +310,13 @@
{
struct { u_char blue, green, red, pad; } entry;
+#ifdef __i386__
if (pmi_setpal) {
entry.red = red >> 10;
entry.green = green >> 10;
entry.blue = blue >> 10;
entry.pad = 0;
+
__asm__ __volatile__(
"call *(%%esi)"
: /* no return value */
@@ -318,7 +326,9 @@
"d" (regno), /* EDX */
"D" (&entry), /* EDI */
"S" (&pmi_pal)); /* ESI */
- } else {
+ } else
+#endif /* __i386__ */
+ {
/* without protected mode interface, try VGA registers... */
outb_p(regno, dac_reg);
outb_p(red >> 10, dac_val);
@@ -464,6 +474,7 @@
inverse=1;
else if (! strcmp(this_opt, "redraw"))
ypan=0;
+#ifdef __i386__
else if (! strcmp(this_opt, "ypan"))
ypan=1;
else if (! strcmp(this_opt, "ywrap"))
@@ -474,6 +485,7 @@
pmi_setpal=1;
else if (! strcmp(this_opt, "mtrr"))
mtrr=1;
+#endif /* __i386__ */
else if (!strncmp(this_opt, "font:", 5))
strcpy(fb_info.fontname, this_opt+5);
}
@@ -541,6 +553,13 @@
printk(KERN_INFO "vesafb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
video_width, video_height, video_bpp, video_linelength, screen_info.pages);
+ vesafb_defined.xres=video_width;
+ vesafb_defined.yres=video_height;
+ vesafb_defined.xres_virtual=video_width;
+ vesafb_defined.yres_virtual=video_size / video_linelength;
+ vesafb_defined.bits_per_pixel=video_bpp;
+
+#ifdef __i386__
if (screen_info.vesapm_seg) {
printk(KERN_INFO "vesafb: protected mode interface info at %04x:%04x\n",
screen_info.vesapm_seg,screen_info.vesapm_off);
@@ -572,16 +591,12 @@
}
}
- vesafb_defined.xres=video_width;
- vesafb_defined.yres=video_height;
- vesafb_defined.xres_virtual=video_width;
- vesafb_defined.yres_virtual=video_size / video_linelength;
- vesafb_defined.bits_per_pixel=video_bpp;
-
if (ypan && vesafb_defined.yres_virtual > video_height) {
printk(KERN_INFO "vesafb: scrolling: %s using protected mode interface, yres_virtual=%d\n",
(ypan > 1) ? "ywrap" : "ypan",vesafb_defined.yres_virtual);
- } else {
+ } else
+#endif /* __i386__ */
+ {
printk(KERN_INFO "vesafb: scrolling: redraw\n");
vesafb_defined.yres_virtual = video_height;
ypan = 0;
@@ -634,6 +649,7 @@
* region already (FIXME) */
request_region(0x3c0, 32, "vesafb");
+#ifdef __i386__
if (mtrr) {
int temp_size = video_size;
/* Find the largest power-of-two */
@@ -645,7 +661,8 @@
temp_size >>= 1;
}
}
-
+#endif
+
strcpy(fb_info.modename, "VESA VGA");
fb_info.changevar = NULL;
fb_info.node = -1;
===== arch/ppc/platforms/prep_setup.c 1.68 vs edited =====
--- 1.68/arch/ppc/platforms/prep_setup.c Thu Jan 17 14:34:06 2002
+++ edited/arch/ppc/platforms/prep_setup.c Wed Jan 23 10:30:30 2002
@@ -287,6 +287,45 @@
}
#endif /* CONFIG_SOUND_CS4232 */
+/*
+ * Fill out screen_info according to the residual data. This allows us to use
+ * at least vesafb.
+ */
+static void __init
+prep_init_vesa(void)
+{
+#if defined(CONFIG_PREP_RESIDUAL)
+ PPC_DEVICE *vgadev;
+
+ vgadev = residual_find_device(~0, NULL, DisplayController, SVGAController,
+ -1, 0);
+ if (vgadev != NULL) {
+ PnP_TAG_PACKET *pkt;
+
+ pkt = PnP_find_large_vendor_packet(
+ (unsigned char *)&res->DevicePnPHeap[vgadev->AllocatedOffset],
+ 0x04, 0); /* 0x04 = Display Tag */
+ if (pkt != NULL) {
+ unsigned char *ptr = (unsigned char *)pkt;
+
+ if (ptr[4]) {
+ /* graphics mode */
+ screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB;
+
+ screen_info.lfb_depth = ptr[4] * 8;
+
+ screen_info.lfb_width = swab16(*(short *)(ptr+6));
+ screen_info.lfb_height = swab16(*(short *)(ptr+8));
+ screen_info.lfb_linelength = swab16(*(short *)(ptr+10));
+
+ screen_info.lfb_base = swab32(*(long *)(ptr+12));
+ screen_info.lfb_size = swab32(*(long *)(ptr+20)) / 65536;
+ }
+ }
+ }
+#endif /* CONFIG_PREP_RESIDUAL */
+}
+
static void __init
prep_setup_arch(void)
{
@@ -353,6 +392,8 @@
#ifdef CONFIG_SOUND_CS4232
prep_init_sound();
#endif /* CONFIG_SOUND_CS4232 */
+
+ prep_init_vesa();
/*print_residual_device_info();*/
===== arch/ppc/kernel/setup.c 1.95 vs edited =====
--- 1.95/arch/ppc/kernel/setup.c Tue Jan 8 03:02:38 2002
+++ edited/arch/ppc/kernel/setup.c Wed Jan 23 10:10:33 2002
@@ -99,7 +99,7 @@
int ucache_bsize;
#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_FB_VGA16) || \
- defined(CONFIG_FB_VGA16_MODULE)
+ defined(CONFIG_FB_VGA16_MODULE) || defined(CONFIG_FB_VESA)
struct screen_info screen_info = {
0, 25, /* orig-x, orig-y */
0, /* unused */
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: RFC: vesafb
2002-01-23 19:20 RFC: vesafb hollis
@ 2002-01-24 4:42 ` Michel Lanners
2002-01-24 22:17 ` hollis
2002-01-24 8:52 ` Geert Uytterhoeven
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ messages in thread
From: Michel Lanners @ 2002-01-24 4:42 UTC (permalink / raw)
To: hollis; +Cc: linuxppc-dev, sdi
On 23 Jan, this message from hollis@austin.ibm.com echoed through cyberspace:
> The attached patch allows vesafb to work on PPC. vesafb does surprisingly
> little with the BIOS (which I thought was the whole point of VESA). With some
> ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
> the card, and the driver just uses it and never mucks with it.
Wouldn't this be a good start to use generic PC-type grafic cards on PPC
machines in general? Or do you lack initialization if nobody (neither
firmware nor OS) can talk to the card 'natively'?
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: RFC: vesafb
2002-01-24 4:42 ` Michel Lanners
@ 2002-01-24 22:17 ` hollis
2002-01-25 9:28 ` Gabriel Paubert
0 siblings, 1 reply; 8+ messages in thread
From: hollis @ 2002-01-24 22:17 UTC (permalink / raw)
To: Michel Lanners; +Cc: linuxppc-dev
On Thu, Jan 24, 2002 at 05:42:46AM +0100, Michel Lanners wrote:
> On 23 Jan, this message from hollis@austin.ibm.com echoed through cyberspace:
> > The attached patch allows vesafb to work on PPC. vesafb does surprisingly
> > little with the BIOS (which I thought was the whole point of VESA). With
> > some ifdef's I'm able to use it as sort of a VGA offb -- the firmware
> > initializes the card, and the driver just uses it and never mucks with it.
>
> Wouldn't this be a good start to use generic PC-type grafic cards on PPC
> machines in general? Or do you lack initialization if nobody (neither
> firmware nor OS) can talk to the card 'natively'?
Yes, we would lack initialization on Power Mac (for example). PReP firmware
does proper setup for a very limited range of chips, which is why this is
useful at all.
-Hollis
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: vesafb
2002-01-24 22:17 ` hollis
@ 2002-01-25 9:28 ` Gabriel Paubert
0 siblings, 0 replies; 8+ messages in thread
From: Gabriel Paubert @ 2002-01-25 9:28 UTC (permalink / raw)
To: hollis; +Cc: Michel Lanners, linuxppc-dev
On Thu, 24 Jan 2002 hollis@austin.ibm.com wrote:
>
> On Thu, Jan 24, 2002 at 05:42:46AM +0100, Michel Lanners wrote:
> > On 23 Jan, this message from hollis@austin.ibm.com echoed through cyberspace:
> > > The attached patch allows vesafb to work on PPC. vesafb does surprisingly
> > > little with the BIOS (which I thought was the whole point of VESA). With
> > > some ifdef's I'm able to use it as sort of a VGA offb -- the firmware
> > > initializes the card, and the driver just uses it and never mucks with it.
> >
> > Wouldn't this be a good start to use generic PC-type grafic cards on PPC
> > machines in general? Or do you lack initialization if nobody (neither
> > firmware nor OS) can talk to the card 'natively'?
>
> Yes, we would lack initialization on Power Mac (for example). PReP firmware
> does proper setup for a very limited range of chips, which is why this is
> useful at all.
I remind you that I am using since 3 years or so an x86 emulator which
should allow to initialize any board with has an x86 ROM BIOS, provided
the host bridge can be configured to generate VGA memory accesses
(0xa0000-0xbffff), so I think most MACs are out. It is in my bootloader
but I have no time to work on it right now, some people have expressed
interest in including it in the official source tree but I don't believe
it will happen soon.
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: vesafb
2002-01-23 19:20 RFC: vesafb hollis
2002-01-24 4:42 ` Michel Lanners
@ 2002-01-24 8:52 ` Geert Uytterhoeven
2002-01-24 18:03 ` Tom Rini
2002-01-25 13:59 ` Leigh Brown
3 siblings, 0 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2002-01-24 8:52 UTC (permalink / raw)
To: hollis; +Cc: Linux/PPC Development, sdi, Linux Frame Buffer Device Development
On Wed, 23 Jan 2002 hollis@austin.ibm.com wrote:
> The attached patch allows vesafb to work on PPC. vesafb does surprisingly
Nice!
> little with the BIOS (which I thought was the whole point of VESA). With some
> ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
> the card, and the driver just uses it and never mucks with it.
Well, vesafb assumes the VESA BIOS initialized the card to some linear graphics
mode _before_ the real kernel code was started. Once the kernel is started, no
VESA calls are made, and the video mode is fixed.
So in theory (and you proved the practical side on PReP) it can be used on any
platform that initializes a more-or-less VGA card to a linear graphics mode.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: RFC: vesafb
2002-01-23 19:20 RFC: vesafb hollis
2002-01-24 4:42 ` Michel Lanners
2002-01-24 8:52 ` Geert Uytterhoeven
@ 2002-01-24 18:03 ` Tom Rini
2002-01-25 9:22 ` Geert Uytterhoeven
2002-01-25 13:59 ` Leigh Brown
3 siblings, 1 reply; 8+ messages in thread
From: Tom Rini @ 2002-01-24 18:03 UTC (permalink / raw)
To: hollis; +Cc: linuxppc-dev, sdi, Geert Uytterhoeven
On Wed, Jan 23, 2002 at 01:20:10PM -0600, hollis@austin.ibm.com wrote:
> The attached patch allows vesafb to work on PPC. vesafb does surprisingly
> little with the BIOS (which I thought was the whole point of VESA). With some
> ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
> the card, and the driver just uses it and never mucks with it.
This looks good to me. My only comment is you should probably use
CONFIG_MTRR around the mtrr bits instead of __i386__ (which is what
other drivers do). Geert, since you're still overall fb maintainer
(yes?) would you be willing to sign off on these changes to be sent to
Marcelo for 2.4.19-pre1?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: vesafb
2002-01-24 18:03 ` Tom Rini
@ 2002-01-25 9:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2002-01-25 9:22 UTC (permalink / raw)
To: Tom Rini; +Cc: hollis, Linux/PPC Development, sdi
On Thu, 24 Jan 2002, Tom Rini wrote:
> On Wed, Jan 23, 2002 at 01:20:10PM -0600, hollis@austin.ibm.com wrote:
> > The attached patch allows vesafb to work on PPC. vesafb does surprisingly
> > little with the BIOS (which I thought was the whole point of VESA). With some
> > ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
> > the card, and the driver just uses it and never mucks with it.
>
> This looks good to me. My only comment is you should probably use
> CONFIG_MTRR around the mtrr bits instead of __i386__ (which is what
Indeed.
> other drivers do). Geert, since you're still overall fb maintainer
What's in a name...
> (yes?) would you be willing to sign off on these changes to be sent to
> Marcelo for 2.4.19-pre1?
Just send them to Marcelo, CC me, and say it's OK for me to include them.
Or better, ask Gerd Knorr to send them in (please CC me)?
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: vesafb
2002-01-23 19:20 RFC: vesafb hollis
` (2 preceding siblings ...)
2002-01-24 18:03 ` Tom Rini
@ 2002-01-25 13:59 ` Leigh Brown
3 siblings, 0 replies; 8+ messages in thread
From: Leigh Brown @ 2002-01-25 13:59 UTC (permalink / raw)
To: hollis; +Cc: linuxppc-dev, sdi
Hi Hollis,
> The attached patch allows vesafb to work on PPC. vesafb does
> surprisingly little with the BIOS (which I thought was the whole point
> of VESA). With some ifdef's I'm able to use it as sort of a VGA offb --
> the firmware initializes the card, and the driver just uses it and
> never mucks with it.
>
> This patch allows me to get an 800x600x8 console on the Thinkpad 850,
> and 640x480x8 on the Carolina machines. More interestingly it allows X
> to work on the Thinkpad, which currently doesn't work and has never
> worked in >16 colors. It should also work on the 7020 (Sven?), which
> uses the Weitek 9100 card and currently is driverless.
>
> This patch is only for PReP, which is probably the only place it's
> really useful (since CHRP and PMac have offb), but would be easy enough
> to add to.
>
> Comments?
Well, I thought I'd give it a go on my 7043-140. I think that it
would help those people with the proprietary IBM graphics cards
(GXT550P, GXT800P that sort of thing, IIRC), as well as being at least
as good as the S3Triofb frame buffer driver (which can't switch video
modes any way).
Unsurprisingly it didn't work. That is, unsurprisingly because nothing
ever goes to plan on these boxes :-)
It seems there is no residual data entry for the graphics card. I
enabled the code to dump the residual data and it was conspicuous by
its absence. In fact, everything else seemed to be there (6 PCI devices
and 17 ISA devices).
Any ideas?
Cheers,
Leigh.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-01-25 13:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-23 19:20 RFC: vesafb hollis
2002-01-24 4:42 ` Michel Lanners
2002-01-24 22:17 ` hollis
2002-01-25 9:28 ` Gabriel Paubert
2002-01-24 8:52 ` Geert Uytterhoeven
2002-01-24 18:03 ` Tom Rini
2002-01-25 9:22 ` Geert Uytterhoeven
2002-01-25 13:59 ` Leigh Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).