Re: Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

Re: Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[maximilian attems]

dear adaplas,

could you please take a look at this matroxfb debian bug report:
http://bugs.debian.org/347186

On Mon, 09 Jan 2006, Steve Langasek wrote:

<snipp>
> > > Sigh, can't get a break with alpha kernel support around here.  After
> > > upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works
> > > correctly on my alpha with a Matrox Millenium II.  The matroxfb_base module
> > > loads without error, but gives me corrupt video output only.
> 
> > Try turning off acceleration.
> 
> Doesn't make a difference.
> 
> What did make a difference was, after googling, loading fbcon manually
> before loading matroxfb_base.  Given that I'm loading matroxfb_base by hand
> (/etc/modules), it's not getting loaded via udev or anything like that, it
> seems to me that it's my responsibility to load fbcon by hand as well, but
> it's still something of an unexpected change from 2.4.  It might be nice to
> have these modules all autoloaded by something, but it's not strictly
> necessary, and some users may not want the framebuffer activated
> automatically?
> 
> The other issue (and the first thing I was trying to get work, which led me
> to believe the fb was completely broken) is that, even though console works
> on the framebuffer now, X does not.  This breakage corresponds to the kernel
> upgrade, not to any changes in X, so still looks like a kernel bug to me.
> 
> If I turn off "UseFBDev" in my xorg.conf, X displays correctly.  I haven't
> poked yet to see what this does performance-wise.
> 
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon@debian.org                                   http://www.debian.org/

2.6.15 has matroxfb patches, did it make a difference on your box?


-- 
maks


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Antonino A. Daplas]

maximilian attems wrote:
> dear adaplas,
> 
> could you please take a look at this matroxfb debian bug report:
> http://bugs.debian.org/347186
> 
> On Mon, 09 Jan 2006, Steve Langasek wrote:
> 
> <snipp>
>>>> Sigh, can't get a break with alpha kernel support around here.  After
>>>> upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works
>>>> correctly on my alpha with a Matrox Millenium II.  The matroxfb_base module
>>>> loads without error, but gives me corrupt video output only.
>>> Try turning off acceleration.
>> Doesn't make a difference.
>>
>> What did make a difference was, after googling, loading fbcon manually
>> before loading matroxfb_base.  Given that I'm loading matroxfb_base by hand
>> (/etc/modules), it's not getting loaded via udev or anything like that, it
>> seems to me that it's my responsibility to load fbcon by hand as well, but
>> it's still something of an unexpected change from 2.4.

You can always compile fbcon statically and the fbdev as modules so you get
the same behavior as 2.4.  (The separation of fbdev from fbcon is advantageous
in embedded systems where the console is not needed).

(There's a new document Documentation/fb/fbcon.txt that explains some of the
changes. It's new in 2.6.15).
 
>>  It might be nice to
>> have these modules all autoloaded by something, but it's not strictly
>> necessary, and some users may not want the framebuffer activated
>> automatically?

As long as fbcon is compiled statically, you'll get the same 2.4 behavior.

>>
>> The other issue (and the first thing I was trying to get work, which led me
>> to believe the fb was completely broken) is that, even though console works
>> on the framebuffer now, X does not.  This breakage corresponds to the kernel
>> upgrade, not to any changes in X, so still looks like a kernel bug to me.
>>
>> If I turn off "UseFBDev" in my xorg.conf, X displays correctly.  I haven't
>> poked yet to see what this does performance-wise.

The "UseFBDev" option was added to X so it can cooperate with fbcon (ie, allows
X to restore the console state by using the fbdev API ).  In 2.6, fbcon has its
own way of restoring its own state so the "UseFBDev" option is not needed, and in
your case, is counterproductive.

(I don't think removing the "UseFBDev" option will affect X performance-wise.)

Tony

Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Sven Luther]

On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote:
> maximilian attems wrote:
> > dear adaplas,
> > 
> > could you please take a look at this matroxfb debian bug report:
> > http://bugs.debian.org/347186
> > 
> > On Mon, 09 Jan 2006, Steve Langasek wrote:
> > 
> > <snipp>
> >>>> Sigh, can't get a break with alpha kernel support around here.  After
> >>>> upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works
> >>>> correctly on my alpha with a Matrox Millenium II.  The matroxfb_base module
> >>>> loads without error, but gives me corrupt video output only.
> >>> Try turning off acceleration.
> >> Doesn't make a difference.
> >>
> >> What did make a difference was, after googling, loading fbcon manually
> >> before loading matroxfb_base.  Given that I'm loading matroxfb_base by hand
> >> (/etc/modules), it's not getting loaded via udev or anything like that, it
> >> seems to me that it's my responsibility to load fbcon by hand as well, but
> >> it's still something of an unexpected change from 2.4.
> 
> You can always compile fbcon statically and the fbdev as modules so you get
> the same behavior as 2.4.  (The separation of fbdev from fbcon is advantageous
> in embedded systems where the console is not needed).
> 
> (There's a new document Documentation/fb/fbcon.txt that explains some of the
> changes. It's new in 2.6.15).

Also, note : 

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311815
  [powerpc] screen garbage when using matroxfb acceleration

this is on powerpc64 though, so it may be some 64-bitness issue.

Friendly,

Sven Luther

Re: Re: Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Antonino A. Daplas]

Sven Luther wrote:
> On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote:
>> maximilian attems wrote:
> 
> Also, note : 
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311815
>   [powerpc] screen garbage when using matroxfb acceleration
> 
> this is on powerpc64 though, so it may be some 64-bitness issue.

Yes.  Reading that bug report, the problem is specific to matroxfb's
hardware acceleration. Petr Vandrovec is the best person for this
problem.

Tony 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Bug#347186: [Linux-fbdev-devel] Re: Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Sven Luther]

On Wed, Jan 11, 2006 at 08:36:16PM +0800, Antonino A. Daplas wrote:
> Sven Luther wrote:
> > On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote:
> >> maximilian attems wrote:
> > 
> > Also, note : 
> > 
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311815
> >   [powerpc] screen garbage when using matroxfb acceleration
> > 
> > this is on powerpc64 though, so it may be some 64-bitness issue.
> 
> Yes.  Reading that bug report, the problem is specific to matroxfb's
> hardware acceleration. Petr Vandrovec is the best person for this
> problem.

Ok, thanks, will forward it to him this WE.

Friendly,

Sven Luther

Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Steve Langasek]

[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]

On Wed, Jan 11, 2006 at 11:28:27AM +0100, maximilian attems wrote:

> > > > Sigh, can't get a break with alpha kernel support around here.  After
> > > > upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works
> > > > correctly on my alpha with a Matrox Millenium II.  The matroxfb_base module
> > > > loads without error, but gives me corrupt video output only.

> > > Try turning off acceleration.

> > Doesn't make a difference.

> > What did make a difference was, after googling, loading fbcon manually
> > before loading matroxfb_base.  Given that I'm loading matroxfb_base by hand
> > (/etc/modules), it's not getting loaded via udev or anything like that, it
> > seems to me that it's my responsibility to load fbcon by hand as well, but
> > it's still something of an unexpected change from 2.4.  It might be nice to
> > have these modules all autoloaded by something, but it's not strictly
> > necessary, and some users may not want the framebuffer activated
> > automatically?

> > The other issue (and the first thing I was trying to get work, which led me
> > to believe the fb was completely broken) is that, even though console works
> > on the framebuffer now, X does not.  This breakage corresponds to the kernel
> > upgrade, not to any changes in X, so still looks like a kernel bug to me.

> > If I turn off "UseFBDev" in my xorg.conf, X displays correctly.  I haven't
> > poked yet to see what this does performance-wise.

> 2.6.15 has matroxfb patches, did it make a difference on your box?

Don't know yet, thanks to bug #347556. :)

On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote:

> >>  It might be nice to
> >> have these modules all autoloaded by something, but it's not strictly
> >> necessary, and some users may not want the framebuffer activated
> >> automatically?

> As long as fbcon is compiled statically, you'll get the same 2.4 behavior.

<nod>  I leave it to Norbert to decide what the policy should be for fbcon
in the alpha kernel images.

> >> The other issue (and the first thing I was trying to get work, which led me
> >> to believe the fb was completely broken) is that, even though console works
> >> on the framebuffer now, X does not.  This breakage corresponds to the kernel
> >> upgrade, not to any changes in X, so still looks like a kernel bug to me.

> >> If I turn off "UseFBDev" in my xorg.conf, X displays correctly.  I haven't
> >> poked yet to see what this does performance-wise.

> The "UseFBDev" option was added to X so it can cooperate with fbcon (ie, allows
> X to restore the console state by using the fbdev API ).  In 2.6, fbcon has its
> own way of restoring its own state so the "UseFBDev" option is not needed, and in
> your case, is counterproductive.

Aha, didn't know that.  It had been my impression that this option meant
using the fbdev API for all vidcard access; but I guess that's the fbdev
driver, anyway.

So the real target for all of this was to get matroxfb working to the point
of running bterm successfully from the debian installer; and even with fbcon
working, in 2.6.14 running bterm or fbi gives me a whole lot of nothing
(console blanks, nothing gets displayed).  I'll give this another try with
2.6.15 once I've got my /usr partition mounting again.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Bug#347186: [Linux-fbdev-devel] Re: Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer

[Michel Dänzer]

On Wed, 2006-01-11 at 21:15 -0800, Steve Langasek wrote:
> On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote:
> 
> > The "UseFBDev" option was added to X so it can cooperate with fbcon (ie, allows
> > X to restore the console state by using the fbdev API ).  In 2.6, fbcon has its
> > own way of restoring its own state so the "UseFBDev" option is not needed, and in
> > your case, is counterproductive.
> 
> Aha, didn't know that.  It had been my impression that this option meant
> using the fbdev API for all vidcard access;

It does, for the things the fbdev API provides.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer