linux-fbdev-users — Generic mailing list for users of frame buffers

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

On Wednesday 10 November 2004 04:29, David Liontooth wrote:
> Antonino A. Daplas wrote:
> > If you have sample XFree86 modelines, you can use the utility
> >
> >modeline2fb to convert them to entries compatible with /etc/fb.modes.
>
> Got it -- in Debian, it's part of the fbset package.
>
> >If I have time, I'll see what's wrong with fbxine.
>
> That would be awesome -- the ability to play movies in the framebuffer
> was the first reason I wanted it, since it would drain the batteries less
> than running movies in KDE.
>
> For some reason, fbxine has stopped working altogether -- I've tried to
> reconstruct
> the environment in which it worked, but now it just displays the
> previous console
> page and exits. fbi works great -- slideshows, autoscaling, rotation,
> the works.
>
> I'll test mplayer again too -- it sounds like this may be an mplayer
> problem.
>
> The main remaining annoyance is that you can't remove the rivafb module,

You can actually, as long as you don't enable the framebuffer console. This
sequence should work:

modprobe rivafb
mplayer -vo directfb
rmmod rivafb

Of course you will only have a vga console.

> so you
> have to reboot to let the nv or nvidia module take over.

The rivafb driver and nv should nicely coexist.  The nvidia driver is still
not compatible with rivafb.

Tony

Re: [Linux-fbdev-users] rivafb + NV17

[David L. <lio...@co...>]

Antonino A. Daplas wrote:

> If you have sample XFree86 modelines, you can use the utility
>
>modeline2fb to convert them to entries compatible with /etc/fb.modes.
>  
>
Got it -- in Debian, it's part of the fbset package.

>If I have time, I'll see what's wrong with fbxine.
>  
>
That would be awesome -- the ability to play movies in the framebuffer
was the first reason I wanted it, since it would drain the batteries less
than running movies in KDE.

For some reason, fbxine has stopped working altogether -- I've tried to 
reconstruct
the environment in which it worked, but now it just displays the 
previous console
page and exits. fbi works great -- slideshows, autoscaling, rotation, 
the works.

I'll test mplayer again too -- it sounds like this may be an mplayer 
problem.

The main remaining annoyance is that you can't remove the rivafb module, 
so you
have to reboot to let the nv or nvidia module take over.

Cheers,
Dave

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

On Tuesday 09 November 2004 11:26, David Liontooth wrote:
> Antonino A. Daplas wrote:
> >On Friday 05 November 2004 18:21, David Liontooth wrote:
>
> Hi Tony,
>
> Thank you! That did the trick. I now have a framebuffer of any size,
> including my 1280x854 monitor.
> How do I generate new entries for /etc/fb.modes? I know the 1280x854
> entry I use is slightly wrong,

If you have sample XFree86 modelines, you can use the utility
modeline2fb to convert them to entries compatible with /etc/fb.modes.

Or you can use the VESA GTF (Generalized Timing Formula).  There
are several utilities as well as online calculators that will generate mode
timings for you based on the GTF.

You can easily do a google search for both of them.

> but evidently not wrong enough to cause problems, and a 720x480 entry I
> tried to create failed.
>
> I'm now able to run slideshows using fbi, and the results are excellent!
> I also tried to play videos,
> and fbxine will play stuff, the sound is fine, the speed is correct, but
> the colors are all swapped. Is

The rivafb driver uses DirectColor and several applications have
difficulties with this mode since they assume that Truecolor and Directcolor
are the same.  (Most applications are used to Truecolor).

If I have time, I'll see what's wrong with fbxine.

> there anything I can do? I also tried mplayer -vo fbdev, but that didn't
> work -- it looks like mplayer
> tries to scale the framebuffer to the size of the movie and fails if
> that size is not available.

I get the same thing to, not just rivafb.  Similarly, once I have time, I'll
try to examine this.

>
> This is very cool and I really appreciate your patch. It would be great
> to have this in the kernel.

I already submitted the patch.

Tony

Re: [Linux-fbdev-users] rivafb + NV17

[David L. <lio...@co...>]

Antonino A. Daplas wrote:

>On Friday 05 November 2004 18:21, David Liontooth wrote:
>  
>
>>On the 2.6.9 kernel on Debian sid, rivafb loads successfully:
>>
>>ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
>>rivafb: nVidia device/chipset 10DE0176
>>rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M]
>>rivafb: flatpanel support enabled
>>rivafb: Detected CRTC controller 1 being used
>>rivafb: RIVA MTRR set to ON
>>rivafb: could not retrieve EDID from DDC/I2C
>>rivafb: setting virtual Y resolution to 52428
>>rivafb: Detected CRTC controller 1 being used
>>rivafb: Detected CRTC controller 1 being used
>>Console: switching to colour frame buffer device 80x30
>>rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000)
>>
>>Along with rivafb, these modules load:
>>
>>Module                  Size  Used by
>>rivafb                 49924  1
>>i2c_algo_bit            8968  1 rivafb
>>vgastate                9472  1 rivafb
>>cfbimgblt               2944  1 rivafb
>>i2c_core               19088  2 rivafb,i2c_algo_bit
>>
>>As long as the proprietary nvidia kernel module is not loaded, this works
>>fine.
>>
>>However, I'm only getting 640x480. My /etc/fb.modes has lots of other
>>resolutions, but they're not accepted.
>>
>>Is this a limitation of the rivafb driver, my hardware, or something else?
>>    
>>
>
>Nope,  it's a bug in the rivafb driver when the EDID block cannot be accessed.
>
>I can't submit a patch right now, but I'll give instructions on how to fix this:
>
>1. open drivers/video/riva/fbdev.c
>2. search for the function "static int __devinit rivafb_probe".
>3. Somewhere near the end you should see these lines:
>
>	fb_destroy_modedb(info->monspecs.modedb);
>	info->monspecs.modedb_len = 0;
>	info->monspecs.modedb = NULL;
>
>4. Remove the line "info->monspecs.modedb_len = 0"
>5. Next, search for the function "static int rivafb_check_var"
>6. Look for these lines:
>
>	if (!mode_valid && !list_empty(&info->modelist))
>		return -EINVAL;
>
>7. Change it so it becomes like this:
>
>	if (!mode_valid && info->monspecs.modedb_len)
>		return -EINVAL;
>
>8. Recompile and reboot. The end effect is rivafb will accept
>all modelines coming from fbset as gospel truth.
>
>Tony
>
>
>  
>
Hi Tony,

Thank you! That did the trick. I now have a framebuffer of any size, 
including my 1280x854 monitor.
How do I generate new entries for /etc/fb.modes? I know the 1280x854 
entry I use is slightly wrong,
but evidently not wrong enough to cause problems, and a 720x480 entry I 
tried to create failed.

I'm now able to run slideshows using fbi, and the results are excellent! 
I also tried to play videos,
and fbxine will play stuff, the sound is fine, the speed is correct, but 
the colors are all swapped. Is
there anything I can do? I also tried mplayer -vo fbdev, but that didn't 
work -- it looks like mplayer
tries to scale the framebuffer to the size of the movie and fails if 
that size is not available.

This is very cool and I really appreciate your patch. It would be great 
to have this in the kernel.

Cheers,
David

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Elimar R. <rie...@lx...>]

On Sun, 07 Nov 2004 the mental interface of
Antonino A. Daplas told:

> On Sunday 07 November 2004 03:30, Elimar Riesebieter wrote:
> > On Thu, 28 Oct 2004 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > > > On Wed, 27 Oct 2004 the mental interface of
> > > >
> > > > Antonino A. Daplas told:
> > > > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > Can you try choosing the l6 color logo in the kernel kconfig.  Or you=
 can
> > > try this patch instead. Let me know which one or if both works.
> >
> > That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9
>=20
> Ok, too many changes in radeon.  Try this one, specific for 2.6.9.  Note
> that the same fix is available in the bk or mm tree.
>=20
> Tony
>=20
> diff -uprN linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c linux-2.6.=
9/drivers/video/aty/radeon_monitor.c
> --- linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c	2004-11-07 03:45:=
56.000000000 +0800
> +++ linux-2.6.9/drivers/video/aty/radeon_monitor.c	2004-11-07 03:48:14.72=
7342552 +0800
> @@ -8,7 +8,7 @@
> =20
>  static struct fb_var_screeninfo radeonfb_default_var =3D {
>          640, 480, 640, 480, 0, 0, 8, 0,
> -        {0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
> +        {0, 8, 0}, {0, 8, 0}, {0, 8, 0}, {0, 0, 0},
>          0, 0, -1, -1, 0, 39721, 40, 24, 32, 11, 96, 2,
>          0, FB_VMODE_NONINTERLACED
>  };

This one gives me the bootlogo back ;-)

Thx

Elimar

--=20
  Learned men are the cisterns of knowledge,=20
  not the fountainheads ;-)

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Antonino A. D. <ad...@ho...>]

On Sunday 07 November 2004 03:30, Elimar Riesebieter wrote:
> On Thu, 28 Oct 2004 the mental interface of
>
> Antonino A. Daplas told:
> > On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > > On Wed, 27 Oct 2004 the mental interface of
> > >
> > > Antonino A. Daplas told:
> > > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > Can you try choosing the l6 color logo in the kernel kconfig.  Or you can
> > try this patch instead. Let me know which one or if both works.
>
> That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9

Ok, too many changes in radeon.  Try this one, specific for 2.6.9.  Note
that the same fix is available in the bk or mm tree.

Tony

diff -uprN linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c linux-2.6.9/drivers/video/aty/radeon_monitor.c
--- linux-2.6.9-orig/drivers/video/aty/radeon_monitor.c	2004-11-07 03:45:56.000000000 +0800
+++ linux-2.6.9/drivers/video/aty/radeon_monitor.c	2004-11-07 03:48:14.727342552 +0800
@@ -8,7 +8,7 @@
 
 static struct fb_var_screeninfo radeonfb_default_var = {
         640, 480, 640, 480, 0, 0, 8, 0,
-        {0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
+        {0, 8, 0}, {0, 8, 0}, {0, 8, 0}, {0, 0, 0},
         0, 0, -1, -1, 0, 39721, 40, 24, 32, 11, 96, 2,
         0, FB_VMODE_NONINTERLACED
 };

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Elimar R. <rie...@lx...>]

On Thu, 28 Oct 2004 the mental interface of
Antonino A. Daplas told:

> On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> > On Wed, 27 Oct 2004 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> >
> > White cursor is back :-))
>=20
> Great.
>=20
> > Bootlogo isn't shown?
>=20
> Can you try choosing the l6 color logo in the kernel kconfig.  Or you can
> try this patch instead. Let me know which one or if both works.

That patch doesn`t meet drivers/video/aty/radeon_monitor.c in 2.6.9

Ciao

Elimar

--=20
  "Talking much about oneself can also=20
   be a means to conceal oneself."
         -Friedrich Nietzsche

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

On Friday 05 November 2004 21:15, Antonino A. Daplas wrote:
> 7. Change it so it becomes like this:
>
> 	if (!mode_valid && !info->monspecs.modedb_len)
> 		return -EINVAL;
>

Oops.  This should be:

if (!mode_valid && info->monspecs.modedb_len)
 		return -EINVAL;

(No exclamation mark(!))

Tony

Re: [Linux-fbdev-users] rivafb + NV17

[Antonino A. D. <ad...@ho...>]

On Friday 05 November 2004 18:21, David Liontooth wrote:
> On the 2.6.9 kernel on Debian sid, rivafb loads successfully:
>
> ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> rivafb: nVidia device/chipset 10DE0176
> rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M]
> rivafb: flatpanel support enabled
> rivafb: Detected CRTC controller 1 being used
> rivafb: RIVA MTRR set to ON
> rivafb: could not retrieve EDID from DDC/I2C
> rivafb: setting virtual Y resolution to 52428
> rivafb: Detected CRTC controller 1 being used
> rivafb: Detected CRTC controller 1 being used
> Console: switching to colour frame buffer device 80x30
> rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000)
>
> Along with rivafb, these modules load:
>
> Module                  Size  Used by
> rivafb                 49924  1
> i2c_algo_bit            8968  1 rivafb
> vgastate                9472  1 rivafb
> cfbimgblt               2944  1 rivafb
> i2c_core               19088  2 rivafb,i2c_algo_bit
>
> As long as the proprietary nvidia kernel module is not loaded, this works
> fine.
>
> However, I'm only getting 640x480. My /etc/fb.modes has lots of other
> resolutions, but they're not accepted.
>
> Is this a limitation of the rivafb driver, my hardware, or something else?

Nope,  it's a bug in the rivafb driver when the EDID block cannot be accessed.

I can't submit a patch right now, but I'll give instructions on how to fix this:

1. open drivers/video/riva/fbdev.c
2. search for the function "static int __devinit rivafb_probe".
3. Somewhere near the end you should see these lines:

	fb_destroy_modedb(info->monspecs.modedb);
	info->monspecs.modedb_len = 0;
	info->monspecs.modedb = NULL;

4. Remove the line "info->monspecs.modedb_len = 0"
5. Next, search for the function "static int rivafb_check_var"
6. Look for these lines:

	if (!mode_valid && !list_empty(&info->modelist))
		return -EINVAL;

7. Change it so it becomes like this:

	if (!mode_valid && !info->monspecs.modedb_len)
		return -EINVAL;

8. Recompile and reboot. The end effect is rivafb will accept
all modelines coming from fbset as gospel truth.

Tony

[Linux-fbdev-users] rivafb + NV17

[David L. <lio...@co...>]

On the 2.6.9 kernel on Debian sid, rivafb loads successfully:

ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
rivafb: nVidia device/chipset 10DE0176
rivafb: nVidia Corporation NV17 [GeForce4 420 Go 32M]
rivafb: flatpanel support enabled
rivafb: Detected CRTC controller 1 being used
rivafb: RIVA MTRR set to ON
rivafb: could not retrieve EDID from DDC/I2C
rivafb: setting virtual Y resolution to 52428
rivafb: Detected CRTC controller 1 being used
rivafb: Detected CRTC controller 1 being used
Console: switching to colour frame buffer device 80x30
rivafb: PCI nVidia NV17 framebuffer ver 0.9.5b (32MB @ 0xEC000000)

Along with rivafb, these modules load:

Module                  Size  Used by
rivafb                 49924  1
i2c_algo_bit            8968  1 rivafb
vgastate                9472  1 rivafb
cfbimgblt               2944  1 rivafb
i2c_core               19088  2 rivafb,i2c_algo_bit

As long as the proprietary nvidia kernel module is not loaded, this works fine.

However, I'm only getting 640x480. My /etc/fb.modes has lots of other
resolutions, but they're not accepted.

Is this a limitation of the rivafb driver, my hardware, or something else?

vesafb won't load at all.

I run thermoman's lilo, which shows an animated scene -- flying penguins
and so on -- in full screen, so I'm disappointed that I get better 
framebuffer
support in lilo than in the OS!

Can anyone suggest how to get a full screen after boot? X11 uses 1280x854.

Please cc me, I'm not subscribed.

Cheers,
Dave

Re: [Linux-fbdev-users] Re: [RFC] support for real graphics hardware

[Antonino A. D. <ad...@ho...>]

On Friday 29 October 2004 18:11, Ladislav Michl wrote:
> On Fri, Oct 29, 2004 at 08:05:07AM +0800, Antonino A. Daplas wrote:
> > However, it took a lot of pain to separate fbcon from fbdev, and making
> > struct fbcon_ops visible to the fbdev driver is tantamount to reversing
> > everything that was done.  So, no, struct fbcon_ops needs to be invisible
> > from the drivers.
>
> Ah, well... Newport can live with that easily, but it's pain for MGras
> (SGI Octane graphics option). You need to setup very complicated DMA to
> support copy area.
>
> > And fb_fillrect|copyarea|imageblit will have to stay, although you are
> > correct that the above functions are just a subset of tileblitting:-).
>
> Now code looks like:
> fbcon_putcs => fbcon_ops->putcs => info->fbops->fb_imageblit
> fbcon_bmove => fbcon_ops->bmove => info->fbops->fb_copyarea
> fbcon_clear => fbcon_ops->clear => info->fbops->fb_filrect

How about:
fbcon_putcs => fbcon_ops->putcs => info->tileops->tileblit
fbcon_bmove => fbcon_ops->bmove => info->tileops->tilemove
fbcon_clear =>fbcon_ops->clear => info->tileops->tilefill

The functions in fbcon_ops and tileops are very, very similar.

>
> So there are four possibilities for MGras:
> 1) Implement console driver (like newport_con.c). That has clear
>    disadvantage of no mode switching API and will cause troubles with
>    adding DRM.
> 2) Implement copyarea in fb driver. That's very compicated (two DMA
>    transfers - 24bit and 1bit) and slower than invalidating area (that
>    is single 1bit DMA transfer) for bmove. (SGI Octane pages are there:
>    http://helios.et.put.poznan.pl/~sskowron/ip30/)

Within fbcon, it is possible to have an unimplemented bmove.  If the driver uses
redraw, or pan_redraw as a scrolling method, fbcon_bmove will never be
called.  However, fbcon_bmove is required by the upper console layer (vt.c)
as a function necessary when inserting or deleting characters.  So it's 
unavoidable to implement bmove, whether using tilemove, or bitmove.

> 3) Hook fb_con operations from driver. You don't like it.

Why not use info->tileops?
 
> 4) Add option to fbcon which will implement bmove by redrawing affected
>    area rather than copying rectangle.

We already have number 4.  See drivers/video/console/fbcon.c:fbcon_redraw_move.

>
> > > Also having flag for supported font widths would be
> > > nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> > > width efectively (zpattern line is misused for that).
> >
> > We can do this, by adding a field that says that the driver can only do
> > blits if source bitmap width is divisible by 8 pixels. I think vga16fb
> > needs this restriction too.
>
> Ok. I remember such flag was there.

It was present in 2.4, removed in 2.6.

Tony

[Linux-fbdev-users] Re: [RFC] support for real graphics hardware

[Ladislav M. <la...@li...>]

On Fri, Oct 29, 2004 at 08:05:07AM +0800, Antonino A. Daplas wrote:
> However, it took a lot of pain to separate fbcon from fbdev, and making
> struct fbcon_ops visible to the fbdev driver is tantamount to reversing
> everything that was done.  So, no, struct fbcon_ops needs to be invisible
> from the drivers.

Ah, well... Newport can live with that easily, but it's pain for MGras
(SGI Octane graphics option). You need to setup very complicated DMA to
support copy area.

> And fb_fillrect|copyarea|imageblit will have to stay, although you are
> correct that the above functions are just a subset of tileblitting:-).

Now code looks like:
fbcon_putcs => fbcon_ops->putcs => info->fbops->fb_imageblit
fbcon_bmove => fbcon_ops->bmove => info->fbops->fb_copyarea
fbcon_clear => fbcon_ops->clear => info->fbops->fb_filrect

So there are four possibilities for MGras:
1) Implement console driver (like newport_con.c). That has clear
   disadvantage of no mode switching API and will cause troubles with
   adding DRM.
2) Implement copyarea in fb driver. That's very compicated (two DMA
   transfers - 24bit and 1bit) and slower than invalidating area (that
   is single 1bit DMA transfer) for bmove. (SGI Octane pages are there:
   http://helios.et.put.poznan.pl/~sskowron/ip30/)
3) Hook fb_con operations from driver. You don't like it.
4) Add option to fbcon which will implement bmove by redrawing affected
   area rather than copying rectangle.

> > Also having flag for supported font widths would be
> > nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> > width efectively (zpattern line is misused for that).
> 
> We can do this, by adding a field that says that the driver can only do 
> blits if source bitmap width is divisible by 8 pixels. I think vga16fb needs
> this restriction too.

Ok. I remember such flag was there.

> Go ahead, write it.  But, do not make struct fbcon_ops visible to the fbdev
> driver, use the methods in info->tileops instead and set the
> FBINFO_MISC_TILEBLITTING bit in info->flags. The end result should be the same.

I'll do. Informations provided by you are sufficient to write Newport
driver. Let's see what could be done with MGras.

	ladis

Re: [Linux-fbdev-users] [RFC] support for real graphics hardware

[Antonino A. D. <ad...@ho...>]

On Friday 29 October 2004 03:43, Ladislav Michl wrote:
> Hi,
>
> I've playing with idea to implement faked framebufer driver fox SGI
> Newport graphics based on REX3 engine (documentation is here:
> ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/) and fbcon changes
> accepted to 2.6.10-rc1 kicked me to write this post :-)
>
> Now stop reading and see patch below (Note: I didn't test it and even
> tried to compile. It worked with old interface and few tweaks in fbcon,
> but I do not want to spent too much time before some consensus is
> reached)... See drivers/video/console/newport_con.c for putcs
> implementation.
>
> Some video devices act as write-only command pipe. There is no memory
> you can read from, there is even no mapable memory at all.
> However they still can utilize fbdev interface to change resolution and
> for DRM and fbcon to handle fonts settings.
>
> Currently there are two bliting modes: bitblit and tileblit. Extending
> struct fbcon_ops with logo drawing op

This can be done. The logo image can be divided into tiles and fed to
fb_tileblit. But with no users yet, I haven't written any code for it.  (The
potential user is matroxfb though)

> and providing way to register blit
> operations to fb driver itself would allow fb_fillrect, fb_copyarea,
> fb_imageblit and fb_cursor become optional, making wider range of
> hardware happy.

That was one of the goals, in order for matroxfb to support a framebuffer in
text mode, the tileblitting extension was added.

However, it took a lot of pain to separate fbcon from fbdev, and making
struct fbcon_ops visible to the fbdev driver is tantamount to reversing
everything that was done.  So, no, struct fbcon_ops needs to be invisible
from the drivers.

And fb_fillrect|copyarea|imageblit will have to stay, although you are
correct that the above functions are just a subset of tileblitting:-).

> Also having flag for supported font widths would be
> nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> width efectively (zpattern line is misused for that).

We can do this, by adding a field that says that the driver can only do 
blits if source bitmap width is divisible by 8 pixels. I think vga16fb needs
this restriction too.

> These
> modifications would make supporting SGI graphics options easier,
> providing way to change resolution in defined way.
>

Go ahead, write it.  But, do not make struct fbcon_ops visible to the fbdev
driver, use the methods in info->tileops instead and set the
FBINFO_MISC_TILEBLITTING bit in info->flags. The end result should be the same.

Tony

[Linux-fbdev-users] [RFC] support for real graphics hardware

[Ladislav M. <la...@li...>]

Hi,

I've playing with idea to implement faked framebufer driver fox SGI
Newport graphics based on REX3 engine (documentation is here: 
ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/) and fbcon changes
accepted to 2.6.10-rc1 kicked me to write this post :-)

Now stop reading and see patch below (Note: I didn't test it and even
tried to compile. It worked with old interface and few tweaks in fbcon,
but I do not want to spent too much time before some consensus is
reached)... See drivers/video/console/newport_con.c for putcs
implementation.

Some video devices act as write-only command pipe. There is no memory
you can read from, there is even no mapable memory at all.
However they still can utilize fbdev interface to change resolution and
for DRM and fbcon to handle fonts settings.

Currently there are two bliting modes: bitblit and tileblit. Extending
struct fbcon_ops with logo drawing op and providing way to register blit
operations to fb driver itself would allow fb_fillrect, fb_copyarea,
fb_imageblit and fb_cursor become optional, making wider range of
hardware happy. Also having flag for supported font widths would be
nice, because REX3 cannot handle drawing 1bpp images other that 8*x
width efectively (zpattern line is misused for that). These
modifications would make supporting SGI graphics options easier,
providing way to change resolution in defined way.

Comments and ideas are more that welcome.

Thanks,
	ladis

Index: drivers/video/Kconfig
===================================================================
RCS file: /home/cvs/linux/drivers/video/Kconfig,v
retrieving revision 1.29
diff -u -r1.29 Kconfig
--- drivers/video/Kconfig	25 Oct 2004 20:44:39 -0000	1.29
+++ drivers/video/Kconfig	28 Oct 2004 17:43:00 -0000
@@ -373,6 +373,14 @@
 	help
 	  SGI Visual Workstation support for framebuffer graphics.
 
+config FB_NEWPORT
+	bool "SGI Newport"
+	depends on FB && SGI_IP22
+	help
+	  This is the fake frame buffer device driver for SGI Newport
+	  graphics. Since Newport has no mapable video memory, this driver
+	  is good only to run console on the top.
+
 config FB_GBE
 	bool "SGI Graphics Backend frame buffer support"
 	depends on FB && (SGI_IP32 || X86_VISWS)
Index: drivers/video/Makefile
===================================================================
RCS file: /home/cvs/linux/drivers/video/Makefile,v
retrieving revision 1.84
diff -u -r1.84 Makefile
--- drivers/video/Makefile	12 Oct 2004 01:45:47 -0000	1.84
+++ drivers/video/Makefile	28 Oct 2004 17:43:01 -0000
@@ -90,7 +90,7 @@
 obj-$(CONFIG_FB_MAXINE)		  += maxinefb.o  cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_TX3912)		  += tx3912fb.o  cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_AU1100)		  += au1100fb.o fbgen.o
-
+obj-$(CONFIG_FB_NEWPORT)	  += newportfb.o
 
 # Platform or fallback drivers go here
 obj-$(CONFIG_FB_VESA)             += vesafb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
Index: drivers/video/console/fbcon.c
===================================================================
RCS file: /home/cvs/linux/drivers/video/console/fbcon.c,v
retrieving revision 1.20
diff -u -r1.20 fbcon.c
--- drivers/video/console/fbcon.c	25 Oct 2004 20:44:39 -0000	1.20
+++ drivers/video/console/fbcon.c	28 Oct 2004 17:43:31 -0000
@@ -456,6 +456,7 @@
 	}
 }
 
+#if 0
 #ifdef CONFIG_FB_TILEBLITTING
 static void set_blitting_type(struct vc_data *vc, struct fb_info *info,
 			      struct display *p)
@@ -477,6 +478,14 @@
 	fbcon_set_bitops(ops);
 }
 #endif /* CONFIG_MISC_TILEBLITTING */
+#endif
+static void set_blitting_type(struct vc_data *vc, struct fb_info *info,
+			      struct display *p)
+{
+	struct fbcon_ops *ops = (struct fbcon_ops *) info->fbcon_par;
+
+	newport_set_bitops(ops);
+}
 
 /**
  *	set_con2fb_map - map console to frame buffer device
Binary files /dev/zero and drivers/video/newportfb.c differ
--- /dev/null	2004-10-28 12:38:40.000000000 +0200
+++ drivers/video/newportfb.c	2004-10-28 14:14:13.000000000 +0200
@@ -0,0 +1,534 @@
+/*
+ *  SGI Newport XL fake framebuffer driver
+ *
+ *  Derived from drivers/video/console/newport_con.c
+ *
+ *  Copyright (C) 2004 Ladislav Michl <la...@li...>
+ *  
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License. See the file COPYING in the main directory of this archive for
+ *  more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+
+#include <video/newport.h>
+
+extern unsigned long sgi_gfxaddr;
+
+/* default mode */
+static struct fb_var_screeninfo default_var_high __initdata = {
+	/* 1280x1024, 8bpp */
+	.xres		= 1280,
+	.yres		= 1024,
+	.xres_virtual	= 1280,
+	.yres_virtual	= 1024,
+	.xoffset	= 0,
+	.yoffset	= 0,
+	.bits_per_pixel	= 8,
+	.grayscale	= 0,
+	.red		= { 0, 8, 0 },
+	.green		= { 0, 8, 0 },
+	.blue		= { 0, 8, 0 },
+	.transp		= { 0, 0, 0 },
+	.nonstd		= 0,
+	.activate	= 0,
+	.height		= -1,
+	.width		= -1,
+	.accel_flags	= 0,
+	.pixclock	= 9353,
+	.left_margin	= 20,
+	.right_margin	= 30,
+	.upper_margin	= 37,
+	.lower_margin	= 3,
+	.hsync_len	= 20,
+	.vsync_len	= 3,
+	.sync		= 0,
+	.vmode		= FB_VMODE_NONINTERLACED
+};
+
+static struct fb_videomode default_mode_high __initdata = {
+	/* 1280x1024, 8bpp */
+	.xres		= 1280,
+	.yres		= 1024,
+	.pixclock	= 9353,
+	.left_margin	= 20,
+	.right_margin	= 30,
+	.upper_margin	= 37,
+	.lower_margin	= 3,
+	.hsync_len	= 20,
+	.vsync_len	= 3,
+	.vmode		= FB_VMODE_NONINTERLACED,
+};
+
+struct fb_videomode *default_mode = &default_mode_high;
+struct fb_var_screeninfo *default_var = &default_var_high;
+
+struct newportfb_par {
+	struct newport_regs *npregs;
+	struct fb_var_screeninfo var;
+	int valid;
+};
+
+static unsigned int pseudo_palette[256];
+
+static int newportfb_blank(int blank, struct fb_info *info)
+{
+	unsigned short treg;
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+
+	/* 0 unblank, 1 blank, 2 no vsync, 3 no hsync, 4 off */
+	switch (blank) {
+	case 0:		/* unblank */
+		treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+		newport_vc2_set(npregs, VC2_IREG_CONTROL,
+				(treg | VC2_CTRL_EDISP));
+		break;
+
+	case 1:		/* blank */
+		treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+		newport_vc2_set(npregs, VC2_IREG_CONTROL,
+				(treg & ~(VC2_CTRL_EDISP)));
+		break;
+
+	default:
+		/* Nothing */
+		break;
+	}
+	return 0;
+}
+
+/*
+ *  Set the hardware according to 'par'.
+ */
+static int newportfb_set_par(struct fb_info *info)
+{
+	return 0;
+}
+
+static void newportfb_encode_fix(struct fb_fix_screeninfo *fix,
+				 struct fb_var_screeninfo *var)
+{
+	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+	strcpy(fix->id, "SGI Newport");
+	fix->smem_start = 0;
+	fix->smem_len = 0;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->type_aux = 0;
+	fix->accel = FB_ACCEL_NONE;
+	switch (var->bits_per_pixel) {
+	case 8:
+		fix->visual = FB_VISUAL_PSEUDOCOLOR;
+		break;
+	default:
+		fix->visual = FB_VISUAL_TRUECOLOR;
+		break;
+	}
+	fix->ywrapstep = 0;
+	fix->xpanstep = 0;
+	fix->ypanstep = 0;
+	fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+	fix->mmio_start = sgi_gfxaddr;
+	fix->mmio_len = sizeof(struct newport_regs);
+}
+
+/*
+ *  Check video mode validity, eventually modify var to best match.
+ */
+static int newportfb_check_var(struct fb_var_screeninfo *var,
+			       struct fb_info *info)
+{
+	return 0;
+}
+
+void newport_reset(struct newport_regs *npregs)
+{
+	unsigned short treg;
+	int i;
+
+	newport_wait(npregs);
+	treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+	newport_vc2_set(npregs, VC2_IREG_CONTROL,
+			(treg | VC2_CTRL_EVIDEO));
+
+	treg = newport_vc2_get(npregs, VC2_IREG_CENTRY);
+	newport_vc2_set(npregs, VC2_IREG_RADDR, treg);
+	npregs->set.dcbmode = (NPORT_DMODE_AVC2 | VC2_REGADDR_RAM |
+			       NPORT_DMODE_W2 | VC2_PROTOCOL);
+	for (i = 0; i < 128; i++) {
+		newport_bfwait(npregs);
+		if (i == 92 || i == 94)
+			npregs->set.dcbdata0.byshort.s1 = 0xff00;
+		else
+			npregs->set.dcbdata0.byshort.s1 = 0x0000;
+	}
+
+	/* turn off popup plane */
+	npregs->set.dcbmode = (DCB_XMAP0 | R_DCB_XMAP9_PROTOCOL |
+			       XM9_CRS_CONFIG | NPORT_DMODE_W1);
+	npregs->set.dcbdata0.bybytes.b3 &= ~XM9_PUPMODE;
+	npregs->set.dcbmode = (DCB_XMAP1 | R_DCB_XMAP9_PROTOCOL |
+			       XM9_CRS_CONFIG | NPORT_DMODE_W1);
+	npregs->set.dcbdata0.bybytes.b3 &= ~XM9_PUPMODE;
+
+	npregs->cset.topscan = 0x3ff;
+	npregs->cset.xywin = (4096 << 16) | 4096;
+}
+
+static inline void newport_fillrect(struct newport_regs *npregs,
+				    int x1, int y1, int x2, int y2, int ci)
+{
+	newport_wait(npregs);
+	npregs->set.wrmask = 0xffffffff;
+	npregs->set.drawmode0 = (NPORT_DMODE0_DRAW | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_DOSETUP | NPORT_DMODE0_STOPX |
+				 NPORT_DMODE0_STOPY);
+	npregs->set.colori = ci;
+	npregs->set.xystarti = (x1 << 16) | y1;
+	npregs->go.xyendi = (x2 << 16) | y2;
+}
+
+static inline void newport_copyrect(struct newport_regs *npregs,
+				    int x1, int y1, int x2, int y2,
+				    int w, int h)
+{
+	newport_wait(npregs);
+	npregs->set.drawmode0 = (NPORT_DMODE0_S2S | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_DOSETUP | NPORT_DMODE0_STOPX |
+				 NPORT_DMODE0_STOPY);
+	npregs->set.xystarti = (x1 << 16) | y1;
+	npregs->set.xyendi = (x2 << 16) | y2;
+	npregs->go.xymove = ((w - x1) << 16) | (h - y1);
+}
+
+/* 
+ * Draw 8 pixel width 1bpp image (character) 
+ */
+static void newport_imageblit_1bpp_8(struct newport_regs *npregs,
+				     unsigned char *src, int x, int y,
+				     int h, int fg, int bg)
+{
+	int x2 = x + 8 - 1;
+	int y2 = y + h - 1;
+
+	/* Fill backgroung */
+	newport_fillrect(npregs, x, y, x2, y2, bg);
+
+	/* Set the color and drawing mode. */
+	newport_wait(npregs);
+	npregs->set.colori = fg;
+	npregs->set.drawmode0 = (NPORT_DMODE0_DRAW | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_STOPX | NPORT_DMODE0_ZPENAB |
+				 NPORT_DMODE0_L32);
+	/* Set coordinates for bitmap operation. */
+	npregs->set.xystarti = (x << 16) | y;
+	npregs->set.xyendi = (x2 << 16) | y2;
+	newport_wait(npregs);
+
+	/* Go, baby, go... */
+	while (h--)
+		npregs->go.zpattern = *src++ << 24;
+
+}
+static void newport_imageblit_8bpp(struct newport_regs *npregs,
+				   unsigned char *src, int x, int y,
+				   int w, int h)
+{
+	int x2, y2, dx, dy;
+	uint32_t *img = (uint32_t *) src;
+
+	newport_wait(npregs);
+
+	npregs->set.drawmode1 = DM1_RGBPLANES | 
+				NPORT_DMODE1_CCLT | 
+				NPORT_DMODE1_CCEQ | 
+				NPORT_DMODE1_CCGT | 
+				NPORT_DMODE1_LOSRC |
+				NPORT_DMODE1_DD8 | 
+				NPORT_DMODE1_HD8 | 
+				NPORT_DMODE1_RWPCKD;
+
+	npregs->set.drawmode0 = NPORT_DMODE0_DRAW | 
+				NPORT_DMODE0_BLOCK | 
+				NPORT_DMODE0_CHOST;
+	x2 = x + w;
+	y2 = y + h;
+	npregs->set.xystarti = (x << 16) | y;
+	npregs->set.xyendi = ((x2 - 1) << 16) | (y2 - 1);
+
+	for (dy = y; dy < y2; dy++) {
+		for (dx = x; dx < x2; dx += 4) {
+			npregs->go.hostrw0 = *img;
+			img++;
+		}
+	}
+}
+
+static int newportfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			       unsigned blue, unsigned transp,
+			       struct fb_info *p)
+{
+	struct newportfb_par *par = p->par;
+	struct newport_regs *npregs = par->npregs;
+
+	newport_cmap_setaddr(npregs, regno);
+	newport_cmap_setrgb(npregs, red, green, blue);
+
+	return 0;
+}
+
+static void newportfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
+{
+}
+
+static void newportfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
+{
+}
+
+static void newportfb_imageblit(struct fb_info *p, const struct fb_image *image)
+{
+}
+
+/* 
+ * Newport has no mapable memory
+ */
+static ssize_t newportfb_read(struct file *file, char __user *buf,
+			      size_t count, loff_t *ppos)
+{
+	return -EINVAL;
+}
+
+static ssize_t newportfb_write(struct file *file, const char __user *buf,
+			       size_t count, loff_t *ppos)
+{
+	return -EINVAL;
+}
+
+static int newportfb_mmap(struct fb_info *info, struct file *file,
+			  struct vm_area_struct *vma)
+{
+	return -EINVAL;
+}
+
+static void newport_op_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+			     int sx, int dy, int dx, int height, int width)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+	int x1 = sx << 3;
+	int y1 = sy * vc->vc_font.height;
+	int x2 = dx << 3;
+	int y2 = dy * vc->vc_font.height;
+	int w = width << 3;
+	int h = height * vc->vc_font.height;
+	newport_copyrect(npregs, x1, y1, x2, y2, w, h);
+}
+
+static void newport_op_clear(struct vc_data *vc, struct fb_info *info,
+			     int sy, int sx, int height, int width)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+	int x1 = sx << 3;
+	int y1 = sy * vc->vc_font.height;
+	int x2 = (sx + width) << 3;
+	int y2 = (sy + height) * vc->vc_font.height;
+	/* FIXME: Use correct background color */
+	newport_fillrect(npregs, x1, y1, x2, y2, 0);
+}
+
+static void newport_op_putcs(struct vc_data *vc, struct fb_info *info,
+			     const unsigned short *s, int count, int yy, int xx,
+			     int fg, int bg)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+
+}
+
+static void newport_op_clear_margins(struct vc_data *vc, struct fb_info *info,
+				     int bottom_only)
+{
+	return;
+}
+
+static void newport_op_cursor(struct vc_data *vc, struct fb_info *info,
+			      struct display *p, int mode, int fg, int bg)
+{
+}
+
+void newport_set_ops(struct vc_data *vc, struct fb_info *info,
+		     struct display *p, struct fbcon_ops *ops)
+{
+	ops->bmove = newport_op_bmove;
+	ops->clear = newport_op_clear;
+	ops->putcs = newport_op_putcs;
+	ops->clear_margins = newport_op_clear_margins;
+	ops->cursor = newport_op_cursor;
+}
+
+EXPORT_SYMBOL(newport_set_ops);
+
+static struct fb_ops newportfb_ops = {
+	.owner		= THIS_MODULE,
+	.fb_read	= newportfb_read,
+	.fb_write	= newportfb_write,
+	.fb_check_var	= newportfb_check_var,
+	.fb_set_par	= newportfb_set_par,
+	.fb_setcolreg	= newportfb_setcolreg,
+	.fb_blank	= newportfb_blank,
+	.fb_fillrect	= newportfb_fillrect,
+	.fb_copyarea	= newportfb_copyarea,
+	.fb_imageblit	= newportfb_imageblit,
+	.fb_cursor	= newportfb_cursor,
+	.fb_mmap	= newportfb_mmap,
+};
+
+int __init newportfb_setup(char *options)
+{
+	return 0;
+}
+
+#define TESTVAL 0xdeadbeef
+#define XSTI_TO_FXSTART(val) (((val) & 0xffff) << 11)
+
+static int __init newportfb_probe(struct device *dev)
+{
+	int ret;
+	struct fb_info *info;
+	struct newportfb_par *par;
+	struct newport_regs *npregs;
+	struct platform_device *p_dev = to_platform_device(dev);
+
+	if (!sgi_gfxaddr)
+		return -ENODEV;
+
+	info = framebuffer_alloc(sizeof(struct newportfb_par), &p_dev->dev);
+	if (!info)
+		return -ENOMEM;
+
+	if (!request_mem_region(sgi_gfxaddr, sizeof(struct newport_regs),
+				"Newport")) {
+		printk(KERN_ERR "newportfb: couldn't reserve mmio region\n");
+		ret = -EBUSY;
+		goto out_free_fbinfo;
+	}
+
+	npregs = (struct newport_regs*)
+		 ioremap(sgi_gfxaddr, sizeof(struct newport_regs));
+	if (!npregs) {
+		printk(KERN_ERR "newportfb: couldn't map mmio region\n");
+		ret = -ENXIO;
+		goto out_release_mem_region;
+	}
+
+	npregs->cset.config = NPORT_CFG_GD0;
+	if (newport_wait(npregs)) {
+		ret = -ENODEV;
+		goto out_unmap;
+	}
+
+	npregs->set.xstarti = TESTVAL;
+	if (npregs->set._xstart.word != XSTI_TO_FXSTART(TESTVAL)) {
+		ret = -ENODEV;
+		goto out_unmap;
+	}
+
+	newport_reset(npregs);
+/*
+	newport_get_revisions();
+	newport_get_screensize();
+*/
+	par = info->par;
+	par->npregs = npregs;
+
+	info->currcon = -1;
+	info->fbops = &newportfb_ops;
+	info->pseudo_palette = pseudo_palette;
+	info->flags = FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
+		      FBINFO_HWACCEL_IMAGEBLIT;
+	fb_alloc_cmap(&info->cmap, 256, 0);
+
+	/* turn on default video mode */
+//	if (fb_find_mode(&par->var, info, NULL, NULL, 0,
+//			 default_mode, 8) == 0)
+		par->var = *default_var;
+	info->var = par->var;
+	newportfb_check_var(&par->var, info);
+	newportfb_encode_fix(&info->fix, &info->var);
+
+	if (register_framebuffer(info) < 0) {
+		ret = -ENXIO;
+		printk(KERN_ERR "newportfb: couldn't register framebuffer\n");
+		goto out_unmap;
+	}
+
+	dev_set_drvdata(&p_dev->dev, info);
+
+	return 0;
+
+out_unmap:
+	iounmap((void *)npregs);
+out_release_mem_region:
+	release_mem_region(sgi_gfxaddr, sizeof(struct newport_regs));
+out_free_fbinfo:
+	framebuffer_release(info);
+	return ret;
+}
+
+static int newportfb_remove(struct device* dev)
+{
+	struct platform_device *p_dev = to_platform_device(dev);
+	struct fb_info *info = dev_get_drvdata(&p_dev->dev);
+	struct newportfb_par *par = info->par;
+
+	unregister_framebuffer(info);
+	framebuffer_release(info);
+	iounmap((void *)par->npregs);
+	release_mem_region(sgi_gfxaddr, sizeof(struct newport_regs));
+
+	return 0;
+}
+
+static struct device_driver newportfb_driver = {
+	.name = "newportfb",
+	.bus = &platform_bus_type,
+	.probe = newportfb_probe,
+	.remove = newportfb_remove,
+};
+
+static struct platform_device newportfb_device = {
+	.name = "newportfb",
+};
+
+int __init newportfb_init(void)
+{
+	int ret = driver_register(&newportfb_driver);
+	if (!ret) {
+		ret = platform_device_register(&newportfb_device);
+		if (ret)
+			driver_unregister(&newportfb_driver);
+	}
+	return ret;
+}
+
+void __exit newportfb_exit(void)
+{
+	 driver_unregister(&newportfb_driver);
+}
+
+module_init(newportfb_init);
+module_exit(newportfb_exit);
+
+MODULE_AUTHOR("Ladislav Michl <la...@li...>");
+MODULE_DESCRIPTION("Newport fake framebuffer");
+MODULE_LICENSE("GPL");

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Antonino A. D. <ad...@ho...>]

On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> On Wed, 27 Oct 2004 the mental interface of
>
> Antonino A. Daplas told:
> > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
>
> White cursor is back :-))

Great.

> Bootlogo isn't shown?

Can you try choosing the l6 color logo in the kernel kconfig.  Or you can
try this patch instead. Let me know which one or if both works.

Tony

diff -Nru a/drivers/video/aty/radeon_monitor.c b/drivers/video/aty/radeon_monitor.c
--- a/drivers/video/aty/radeon_monitor.c	2004-10-27 14:58:07 +08:00
+++ b/drivers/video/aty/radeon_monitor.c	2004-10-28 06:04:32 +08:00
@@ -12,9 +12,9 @@
 	.xres_virtual	= 640,
 	.yres_virtual	= 480,
 	.bits_per_pixel = 8,
-	.red		= { 0, 6, 0 },
-	.green		= { 0, 6, 0 },
-	.blue		= { 0, 6, 0 },
+	.red		= { 0, 8, 0 },
+	.green		= { 0, 8, 0 },
+	.blue		= { 0, 8, 0 },
 	.activate	= FB_ACTIVATE_NOW,
 	.height		= -1,
 	.width		= -1,

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Elimar R. <rie...@lx...>]

On Wed, 27 Oct 2004 the mental interface of
Antonino A. Daplas told:

> On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > --- a/drivers/video/console/fbcon.c 2004-10-26 23:49:13 +08:00
> > > +++ b/drivers/video/console/fbcon.c 2004-10-27 08:17:19 +08:00
> > > @@ -1012,7 +1012,9 @@
> > >
> > >  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > >  {
> > > -   fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > > +   unsigned short chr =3D c;
> >
> > I think that you must use scr_write(c, &chr) to get it right.
>=20
> Indeed. Thanks.

White cursor is back :-))
Bootlogo isn't shown?

Ciao

Elimar


--=20
  Never make anything simple and efficient when a way=20
  can be found to make it complex and wonderful ;-)

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Guido G. <ag...@de...>]

On Wed, Oct 27, 2004 at 09:09:43AM +0800, Antonino A. Daplas wrote:
> On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > --- a/drivers/video/console/fbcon.c 2004-10-26 23:49:13 +08:00
> > > +++ b/drivers/video/console/fbcon.c 2004-10-27 08:17:19 +08:00
> > > @@ -1012,7 +1012,9 @@
> > >
> > >  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > >  {
> > > -   fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > > +   unsigned short chr = c;
> >
> > I think that you must use scr_write(c, &chr) to get it right.
> 
> Indeed. Thanks.
Cool. Works here on rivafb!
 -- Guido

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Antonino A. D. <ad...@ho...>]

On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > --- a/drivers/video/console/fbcon.c 2004-10-26 23:49:13 +08:00
> > +++ b/drivers/video/console/fbcon.c 2004-10-27 08:17:19 +08:00
> > @@ -1012,7 +1012,9 @@
> >
> >  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> >  {
> > -   fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > +   unsigned short chr = c;
>
> I think that you must use scr_write(c, &chr) to get it right.

Indeed. Thanks.

Tony

diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	2004-10-26 23:49:13 +08:00
+++ b/drivers/video/console/fbcon.c	2004-10-27 09:07:57 +08:00
@@ -1012,7 +1012,10 @@
 
 static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
 {
-	fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
+	unsigned short chr;
+
+	scr_writew(c, &chr);
+	fbcon_putcs(vc, &chr, 1, ypos, xpos);
 }
 
 static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black

[Petr V. <VAN...@vc...>]

On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> --- a/drivers/video/console/fbcon.c 2004-10-26 23:49:13 +08:00
> +++ b/drivers/video/console/fbcon.c 2004-10-27 08:17:19 +08:00
> @@ -1012,7 +1012,9 @@
>  
>  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
>  {
> -   fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> +   unsigned short chr = c;

I think that you must use scr_write(c, &chr) to get it right.
                                                        Petr Vandrovec
                                                        
> +
> +   fbcon_putcs(vc, &chr, 1, ypos, xpos);
>  }
>  
>  static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
> 
> 

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Antonino A. D. <ad...@ho...>]

On Wednesday 27 October 2004 01:13, Elimar Riesebieter wrote:
> On Tue, 26 Oct 2004 the mental interface of
>
> Antonino A. Daplas told:
> > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > On Mon, 25 Oct 2004 the mental interface of
> > >
> > > Antonino A. Daplas told:
> > > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > > Any hints to get back a white mousecursor and a shown bootlogo as
> > > > > in 2.6.8?
> > > >
> > > > See my other mail for the mousecursor.
> >
> > Can you try booting with video=radeonfb:noaccel?
>
> No changes :(
>

I suspect as much.  I think fbcon_putc might have an endian bug. Can you try
this patch?

Tony

diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	2004-10-26 23:49:13 +08:00
+++ b/drivers/video/console/fbcon.c	2004-10-27 08:17:19 +08:00
@@ -1012,7 +1012,9 @@
 
 static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
 {
-	fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
+	unsigned short chr = c;
+
+	fbcon_putcs(vc, &chr, 1, ypos, xpos);
 }
 
 static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Elimar R. <rie...@lx...>]

On Tue, 26 Oct 2004 the mental interface of
Antonino A. Daplas told:

> On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > On Mon, 25 Oct 2004 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > Hi all,
> > > >
> > > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at bootti=
me.
> > > > The mousecursor is black colored on vt's and can be used as a brush=
 to
> > > > darken the screen.
> > > >
> > > > $ /usr/sbin/fbset
> > > > mode "1280x854-60"
> > > >     # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > > >     geometry 1280 854 1280 854 8
> > > >     timings 12529 128 16 8 1 112 3
> > > >     rgba 8/0,8/0,8/0,0/0
> > > > endmode
> > > >
> > > > $ cat /proc/fb
> > > > 0 ATI Radeon NP
> > > >
> > > > The bootlogo isn`t shown.
> > > >
> > > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > > fine.
> > > >
> > > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > > 2.6.8?
> > >
> > > See my other mail for the mousecursor.
> >
>=20
> Can you try booting with video=3Dradeonfb:noaccel?
No changes :(

$ dmesg | grep radeon
Kernel command line: root=3D/dev/hda5 ro video=3Dradeonfb:noaccel=20
radeonfb: Invalid ROM signature 303 should be 0xaa55
radeonfb: Retreived PLL infos from Open Firmware
radeonfb: Reference=3D27.00 MHz (RefDiv=3D12) Memory=3D200.00 Mhz, System=
=3D300.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type LCD found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
radeonfb: Power Management enabled for Mobility chipsets
radeonfb: ATI Radeon NP  SDR SGRAM 64 MB

Elimar


--=20
  Planung:
  Ersatz des Zufalls durch den Irrtum.
                                -unknown-

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Albert C. <al...@us...>]

On Tue, 2004-10-26 at 10:36, Geert Uytterhoeven wrote:
> On Tue, 26 Oct 2004, Antonino A. Daplas wrote:
> > On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> > > On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > > > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > > > On Mon, 25 Oct 2004 the mental interface of
> > > > Can you try booting with video=radeonfb:noaccel?
> > >
> > > I'm not sure if this has already been mentionend outside of the debian-ppc
> > > list: this also happens with at least rivafb and offb too.
> > 
> > This is the first time I knew about this problem.  Note that gpm
> > predominantly uses the TIOCLINUX ioctl which mainly manipulates the
> > screen_buffer.  
> > 
> > So each time the mouse is moved, gpm sends an ioctl that complements or
> > reverses the attributes of the character underneath the mouse cursor, then
> > it sends a putc command (telling the console to repaint the character). It does
> > not use the fbcon cursor API.
> > 
> > In all drivers I tested in the i386, gpm seems towork correctly.
> > 
> > I can't really much help in this area except for someone with a PPC machine
> > to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
> > selection code in drivers/char/selection.c.
> 
> Just a guess: has anyone recently introduced an endianness-bug somewhere in the
> selection code?

The other common problem is that "char" is unsigned by
default on PowerPC.

**sigh** None of this is necessary. I've used PowerPC in
little-endian mode before, and it works great. Having a
motherboard that does a 64-bit byte swap is helpful for
PCI IO, but certainly not required. On a Mac, you'd simply
need to anti-munge the IO addresses in addition to the
byte swapping that's already done for PCI IO. Also, the
page table entry code needs to order the bits differently,
and loading the MSR may require an extra instruction.

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Geert U. <ge...@li...>]

On Tue, 26 Oct 2004, Antonino A. Daplas wrote:
> On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> > On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > > On Mon, 25 Oct 2004 the mental interface of
> > > Can you try booting with video=radeonfb:noaccel?
> >
> > I'm not sure if this has already been mentionend outside of the debian-ppc
> > list: this also happens with at least rivafb and offb too.
> 
> This is the first time I knew about this problem.  Note that gpm
> predominantly uses the TIOCLINUX ioctl which mainly manipulates the
> screen_buffer.  
> 
> So each time the mouse is moved, gpm sends an ioctl that complements or
> reverses the attributes of the character underneath the mouse cursor, then
> it sends a putc command (telling the console to repaint the character). It does
> not use the fbcon cursor API.
> 
> In all drivers I tested in the i386, gpm seems towork correctly.
> 
> I can't really much help in this area except for someone with a PPC machine
> to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
> selection code in drivers/char/selection.c.

Just a guess: has anyone recently introduced an endianness-bug somewhere in the
selection 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

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Antonino A. D. <ad...@ho...>]

On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > On Mon, 25 Oct 2004 the mental interface of
> > Can you try booting with video=radeonfb:noaccel?
>
> I'm not sure if this has already been mentionend outside of the debian-ppc
> list: this also happens with at least rivafb and offb too.

This is the first time I knew about this problem.  Note that gpm
predominantly uses the TIOCLINUX ioctl which mainly manipulates the
screen_buffer.  

So each time the mouse is moved, gpm sends an ioctl that complements or
reverses the attributes of the character underneath the mouse cursor, then
it sends a putc command (telling the console to repaint the character). It does
not use the fbcon cursor API.

In all drivers I tested in the i386, gpm seems towork correctly.

I can't really much help in this area except for someone with a PPC machine
to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
selection code in drivers/char/selection.c.

Tony

 

Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]

[Guido G. <ag...@de...>]

On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > On Mon, 25 Oct 2004 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > Hi all,
> > > >
> > > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime.
> > > > The mousecursor is black colored on vt's and can be used as a brush to
> > > > darken the screen.
> > > >
> > > > $ /usr/sbin/fbset
> > > > mode "1280x854-60"
> > > >     # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > > >     geometry 1280 854 1280 854 8
> > > >     timings 12529 128 16 8 1 112 3
> > > >     rgba 8/0,8/0,8/0,0/0
> > > > endmode
> > > >
> > > > $ cat /proc/fb
> > > > 0 ATI Radeon NP
> > > >
> > > > The bootlogo isn`t shown.
> > > >
> > > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > > fine.
> > > >
> > > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > > 2.6.8?
> > >
> > > See my other mail for the mousecursor.
> >
> 
> Can you try booting with video=radeonfb:noaccel?
I'm not sure if this has already been mentionend outside of the debian-ppc
list: this also happens with at least rivafb and offb too.
 -- Guido