Just to let people know there's a new version of Petr's ongoing work
with the matrox framebuffer available:
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
the file is called mga-2.5.65.gz, and it works wonderfully.
As far as I know, this patch was only announced on the fbdev-developers
mailing-list. I assume there are more matrox-users here.
Good luck,
Jurriaan
--
Felisin's hands ... ah, they have graped and touched, they have been
slick and they have been soiled, and yet held nothing. Life slips
through them like a ghost.
Steven Erikson - Deadhouse Gates
GNU/Linux 2.5.65-mm3 SMP/ReiserFS 4276 bogomips load av: 0.50 0.25 0.09
On Fri, Mar 21, 2003 at 07:43:37PM +0100, Jurriaan wrote:
> Just to let people know there's a new version of Petr's ongoing work
> with the matrox framebuffer available:
>
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
>
> the file is called mga-2.5.65.gz, and it works wonderfully.
>
> As far as I know, this patch was only announced on the fbdev-developers
> mailing-list. I assume there are more matrox-users here.
>
It applies fine to 2.5.65-mm3 too.
Is this something that could be mergerd? The current
matrox driver don't even compile.
Helge Hafting
> On Fri, Mar 21, 2003 at 07:43:37PM +0100, Jurriaan wrote:
> > Just to let people know there's a new version of Petr's ongoing work
> > with the matrox framebuffer available:
> >
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
> >
> > the file is called mga-2.5.65.gz, and it works wonderfully.
> >
> > As far as I know, this patch was only announced on the fbdev-developers
> > mailing-list. I assume there are more matrox-users here.
> >
> It applies fine to 2.5.65-mm3 too.
> Is this something that could be mergerd? The current
> matrox driver don't even compile.
Its for testing and it hasn't been fully ported over yet. Its close.
I was busy fixing higher level bugs but now that most are fixed I can work
on the matrox driver again.
On Sun, Mar 23, 2003 at 04:50:12PM +0000, James Simmons wrote:
>
> > On Fri, Mar 21, 2003 at 07:43:37PM +0100, Jurriaan wrote:
> > > Just to let people know there's a new version of Petr's ongoing work
> > > with the matrox framebuffer available:
> > >
> > > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
> > >
> > > the file is called mga-2.5.65.gz, and it works wonderfully.
> > >
> > > As far as I know, this patch was only announced on the fbdev-developers
> > > mailing-list. I assume there are more matrox-users here.
> > >
> > It applies fine to 2.5.65-mm3 too.
> > Is this something that could be mergerd? The current
> > matrox driver don't even compile.
>
> Its for testing and it hasn't been fully ported over yet. Its close.
> I was busy fixing higher level bugs but now that most are fixed I can work
> on the matrox driver again.
There are still some open problems (text mode, hardware cursor), and I missed
something somewhere, as czech font works only on VT1 console with mga-2.5.65
(on other VTs there is some font loaded, but character mapping looks broken).
I have no idea whether it is my problem or James's...
Probably worst problem currently is cursor code: it calls imgblit from interrupt
context, and matroxfb's accelerated procedures are not ready to handle
such thing (patch hooks cursor call much sooner for primary mga head).
At worst, for 2.6.0 I can remove text mode from version for Linus, and maintain
text mode capable driver separately, if we'll find some solution for cursor...
Petr Vandrovec
[email protected]
> > Its for testing and it hasn't been fully ported over yet. Its close.
> > I was busy fixing higher level bugs but now that most are fixed I can work
> > on the matrox driver again.
>
> There are still some open problems (text mode, hardware cursor), and I missed
> something somewhere, as czech font works only on VT1 console with mga-2.5.65
> (on other VTs there is some font loaded, but character mapping looks broken).
> I have no idea whether it is my problem or James's...
I have tested font changing. It works.
> Probably worst problem currently is cursor code: it calls imgblit from interrupt
> context, and matroxfb's accelerated procedures are not ready to handle
> such thing (patch hooks cursor call much sooner for primary mga head).
Fixed now. Also I have a patch that properly fixes image.depth = 0 hack. I
will post for people to test. Folks please test the code.
On 25 Mar 03 at 18:16, James Simmons wrote:
> > > Its for testing and it hasn't been fully ported over yet. Its close.
> > > I was busy fixing higher level bugs but now that most are fixed I can work
> > > on the matrox driver again.
> >
> > There are still some open problems (text mode, hardware cursor), and I missed
> > something somewhere, as czech font works only on VT1 console with mga-2.5.65
> > (on other VTs there is some font loaded, but character mapping looks broken).
> > I have no idea whether it is my problem or James's...
>
> I have tested font changing. It works.
I'll have to look into my changes then :-(
> > Probably worst problem currently is cursor code: it calls imgblit from interrupt
> > context, and matroxfb's accelerated procedures are not ready to handle
> > such thing (patch hooks cursor call much sooner for primary mga head).
>
> Fixed now. Also I have a patch that properly fixes image.depth = 0 hack. I
> will post for people to test. Folks please test the code.
AFAIK you only fixed kmalloc problem. Or is cursor callback disallowed
while doing imgblit/copyarea/fillrect ?
Petr Vandrovec
> > > Probably worst problem currently is cursor code: it calls imgblit from interrupt
> > > context, and matroxfb's accelerated procedures are not ready to handle
> > > such thing (patch hooks cursor call much sooner for primary mga head).
> >
> > Fixed now. Also I have a patch that properly fixes image.depth = 0 hack. I
> > will post for people to test. Folks please test the code.
>
> AFAIK you only fixed kmalloc problem. Or is cursor callback disallowed
> while doing imgblit/copyarea/fillrect ?
Take a look at fb_get_buffer_offset in fbmem.c and tell me if it is
enough for you. I do plan to move to using a semaphore instead of a
spinlock tho.
On 25 Mar 03 at 20:48, James Simmons wrote:
> > > > Probably worst problem currently is cursor code: it calls imgblit from interrupt
> > > > context, and matroxfb's accelerated procedures are not ready to handle
> > > > such thing (patch hooks cursor call much sooner for primary mga head).
> > >
> > > Fixed now. Also I have a patch that properly fixes image.depth = 0 hack. I
> > > will post for people to test. Folks please test the code.
> >
> > AFAIK you only fixed kmalloc problem. Or is cursor callback disallowed
> > while doing imgblit/copyarea/fillrect ?
>
> Take a look at fb_get_buffer_offset in fbmem.c and tell me if it is
> enough for you. I do plan to move to using a semaphore instead of a
> spinlock tho.
Problem is not with buffer. Problem is with accelerator... if you
are in the middle of fb_imageblit, reentering it through cursor code
(although with different arguments) is simplest way to kill it...
I hope that it is guarded against by generic console layer by disabling
cursor around putcs, but I'm not sure (and well, apparently there is
something wrong, as when I use accelerated imageblit with 2.5.66-current-bk,
sometime some portions of painted rectangles are missing, like if
info->pixmap buffer got swapped behind accel_putcs back...).
And looking at softcursor code and fb_get_buffer_offset, it looks to me
that softcursor's fb_get_buffer_offset is nowhere compensated, so it
always expires with count == 0, without waiting for its users
(there is nothing to fbsync, putcs code still paints characters into
buffer to put them later to screen), rewritting characters bodies
with cursor data... (I'll not comment about current fb_get_buffer_offset
anymore, as you are rewritting it with semaphores; but current
implementation does not work, caller must disable interrupts from
call to fb_get_buffer_offset to its release, as otherwise you'll deadlock
if you'll remove count==1000 limitation, because if same CPU
owns some portion of buffer while same CPU processes timer interrupt,
code which uses buffer will not make any progress while you are looping
in the interrupt :-( And with (any) count limit you can just remove this
test completely.)
And I'm not sure that s_pitch/d_pitch order is correct in both
calls to move_buf_aligned in softcursor code - I think that both
calls should use same order of s/d pitch - but one uses s/d, while
other d/s.
But maybe that my analysis is completely wrong - I'm using dualhead
configuration, so I had to make couple of changes in cursor code
to have cursor on second head, and there is definitely something wrong
in this, as software underlined cursor looks like '_._' on secondary
head (it looks to me like binary value 0x6B, malloc filler value,
but I want to be sure before claiming it is your problem, but it
looks to me like that 'data' kmalloced in accel_cursor are not set
to any value if FB_CUR_SETSIZE was not set, but softcursor code
uses cursor->image.data always, regardless of FB_CUR_SETSHAPE).
[well, what's cursor->image.data argument supposed to do anyway
at fbops->fb_cursor interface? it looks to me like that it should
be array filled with 0xFF all the time]
And soft_cursor() may call kmalloc(GFP_KERNEL). Same rules as for
two kmallocs in accel_cursor() should apply: GFP_ATOMIC & check
return value (& I would preffer growing-only buffer instead of
reallocating it at every SETSHAPE request - preferrably only
on FB_CUR_SETSIZE).
Petr Vandrovec