Menu
▾
▴
linuxconsole-dev
|
From: Petr V. <VAN...@vc...> - 2003-12-01 16:14:13
|
On 1 Dec 03 at 17:02, Svetoslav Slavtchev wrote:
>
> is this a matroxfb bug ?
Maybe. But I'd say that you broke fbdev API matroxfb expects.
> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x16bpp (virtual: 1024x65536)
> > fbcon_startup: res: 1024x0-16
Like that you are somewhere truncating values to 16 bits?! Thus 65536 == 0
in your arithmetic... And as matroxfb's code does
if (var->yres_virtual > 32767)
var->yres_virtual = 32767;
it is impossible for yres_virtual to ever become 65536... Besides that
for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only
32MB. So you screwed something a lot. You should get
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x16bpp (virtual: 1024x8190)
matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432
Console: switching to colour frame buffer device 128x48
fb0: MATROX frame buffer device
I'd say that if you want support from me, you should use my code...
I have no idea what you are doing in your tree, but you are apparently
doing wrong things...
Petr Vandrovec
|
|
From: Petr V. <VAN...@vc...> - 2003-12-01 18:10:08
|
On 1 Dec 03 at 17:57, Svetoslav Slavtchev wrote:
> > it is impossible for yres_virtual to ever become 65536... Besides that
> > for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only
> > 32MB. So you screwed something a lot. You should get
> >
> > matroxfb: Matrox G550 detected
> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x16bpp (virtual: 1024x8190)
> > matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432
> > Console: switching to colour frame buffer device 128x48
> > fb0: MATROX frame buffer device
>
> two questions
> 1.)
> is there a way to specify yres_virtual,
> i can not see such module option
You cannot specify it - you can only say 'yes, I want virtual scrolling'
or 'no, I do not want it'. If you use 'video=matroxfb:nopan', driver will
use yres_virtual == yres. If you do not specify it, driver attempts
to use largest possible value smaller than 65536. Apparently for some
reason fb_set_var() with yres_virtual == 65536 succeeds without
changing passed var, although it should report back truncated yres_virtual....
oh, stop! There is no fb_set_var call in stock matroxfb. Can you try opening
drivers/video/matrox/matroxfb_base.c in your favorite text editor and
locakte
matroxfb_init_fix(PMINFO2);
err = -EINVAL;
and add
fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
between these two lines there... It should then use proper (~8190) vyres
instead of 64K. But probably vgacon -> matroxfb will stop working after
that, and you'll see whole screen as bright white instead of text
inherited from vgacon.
> 2.)
> how should one adjust the mode for head2,
> matroxfb_crtc2 has only a "mem" option
fbset. crtc2 always begins in 640x480/32bpp, as it cannot be your
boot monitor, so you can always run fbset. Unless you have 2.6.x fbset-less
kernel, in which case you have just bad luck...
> > I'd say that if you want support from me, you should use my code...
> > I have no idea what you are doing in your tree, but you are apparently
> > doing wrong things...
>
> just asking :(
> i'm not a kernel programmer, and i'm not familiar with the fb /console
> internals
> if i was i would try to merge your driver, but i'm not so ...
>
> and as said your driver makes deep changes to the FB API, which IMHO are
> incompatible
> with ruby
Version in kernel just uses standard fbdev API present in 2.6.x kernel.
> i know i can not ask for support at least until 2.7 is open and ruby merged
> into it,
> and even then may be you'll keep your driver out of tree which will
> complicate support questions
Yes, I support only standard Linus (or soon Andrew's) kernel.
Petr
|
|
From: Svetoslav S. <sv...@gm...> - 2003-12-01 19:03:54
|
> On 1 Dec 03 at 17:57, Svetoslav Slavtchev wrote:
> > > it is impossible for yres_virtual to ever become 65536... Besides that
> > > for 1024x65536/16bpp you need 128MB of videoram, and G550 can have
> only
> > > 32MB. So you screwed something a lot. You should get
> > >
> > > matroxfb: Matrox G550 detected
> > > matroxfb: MTRR's turned on
> > > matroxfb: 1024x768x16bpp (virtual: 1024x8190)
> > > matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size
> 33554432
> > > Console: switching to colour frame buffer device 128x48
> > > fb0: MATROX frame buffer device
> >
> > two questions
> > 1.)
> > is there a way to specify yres_virtual,
> > i can not see such module option
>
> You cannot specify it - you can only say 'yes, I want virtual scrolling'
> or 'no, I do not want it'. If you use 'video=matroxfb:nopan', driver will
> use yres_virtual == yres. If you do not specify it, driver attempts
> to use largest possible value smaller than 65536. Apparently for some
> reason fb_set_var() with yres_virtual == 65536 succeeds without
> changing passed var, although it should report back truncated
> yres_virtual....
> oh, stop! There is no fb_set_var call in stock matroxfb. Can you try
> opening
> drivers/video/matrox/matroxfb_base.c in your favorite text editor and
> locakte
>
> matroxfb_init_fix(PMINFO2);
> err = -EINVAL;
>
> and add
>
> fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
>
> between these two lines there... It should then use proper (~8190) vyres
> instead of 64K. But probably vgacon -> matroxfb will stop working after
> that, and you'll see whole screen as bright white instead of text
> inherited from vgacon.
everything lloks OK in dmesg, but running swapped still breaks
both without/with nopan=1
-----withount nopan
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x32bpp (virtual: 1024x4096)
matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
fb0: MATROX frame buffer device
fb0: initializing hardware
matroxfb_crtc2: secondary head of fb0 was registered as fb1
-----with nopan=1
matroxfb: Matrox G550 detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x32bpp (virtual: 1024x768)
matroxfb: framebuffer at 0xD8000000, mapped to 0xe0ca9000, size 16777216
fb0: MATROX frame buffer device
fb0: initializing hardware
matroxfb_crtc2: secondary head of fb0 was registered as fb1
[root@tux root]# fbset -fb /dev/fb0
mode "1024x768-60"
# D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
geometry 1024 768 1024 768 32
timings 15386 160 32 30 4 128 4
accel true
rgba 8/16,8/8,8/0,8/24
endmode
[root@tux root]# matroxfb_swapped
[root@tux root]# fbset -fb /dev/fb0
mode "1024x0-1273"
# D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
geometry 1024 0 1024 0 32
timings 15386 160 32 30 4 128 4
accel true
rgba 8/16,8/8,8/0,8/24
endmode
> > 2.)
> > how should one adjust the mode for head2,
> > matroxfb_crtc2 has only a "mem" option
>
> fbset. crtc2 always begins in 640x480/32bpp, as it cannot be your
> boot monitor, so you can always run fbset. Unless you have 2.6.x
> fbset-less
> kernel, in which case you have just bad luck...
fbdev bk tree should support fbset, but let see when it will be merged in
2.6
/* or in ruby */
> > > I'd say that if you want support from me, you should use my code...
> > > I have no idea what you are doing in your tree, but you are apparently
> > > doing wrong things...
> >
> > just asking :(
> > i'm not a kernel programmer, and i'm not familiar with the fb /console
> > internals
> > if i was i would try to merge your driver, but i'm not so ...
> >
> > and as said your driver makes deep changes to the FB API, which IMHO are
> > incompatible
> > with ruby
>
> Version in kernel just uses standard fbdev API present in 2.6.x kernel.
i ment the driver you actively work on, the one on your ftp/http page
best,
svetljo
--
Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!
Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.
http://www.gmx.net/de/cgi/produktemail
+++ GMX - die erste Adresse für Mail, Message, More! +++
|
|
From: Petr V. <VAN...@vc...> - 2003-12-01 19:14:52
|
On 1 Dec 03 at 20:03, Svetoslav Slavtchev wrote:
> [root@tux root]# fbset -fb /dev/fb0
>
> mode "1024x768-60"
> # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
> geometry 1024 768 1024 768 32
> timings 15386 160 32 30 4 128 4
> accel true
> rgba 8/16,8/8,8/0,8/24
> endmode
> [root@tux root]# matroxfb_swapped
> [root@tux root]# fbset -fb /dev/fb0
>
> mode "1024x0-1273"
> # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
> geometry 1024 0 1024 0 32
> timings 15386 160 32 30 4 128 4
> accel true
> rgba 8/16,8/8,8/0,8/24
> endmode
What does 'matroxfb_swapped' do ? You have not only yres_virtual, but also
yres set to 0. It looks to me like that 'matroxfb_swapped' asked for this...
Driver in kernel is identical to driver on my site, except that features
which are impossible to have with 2.6 fbdev kernel API were removed.
But for mere users who do not need fbset, different resolutions on each
display, textual displays or legacy svga games should not notice any
difference.
Petr
|
|
From: Svetoslav S. <sv...@gm...> - 2003-12-01 19:27:36
|
> On 1 Dec 03 at 20:03, Svetoslav Slavtchev wrote:
>
> > [root@tux root]# fbset -fb /dev/fb0
> >
> > mode "1024x768-60"
> > # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
> > geometry 1024 768 1024 768 32
> > timings 15386 160 32 30 4 128 4
> > accel true
> > rgba 8/16,8/8,8/0,8/24
> > endmode
> > [root@tux root]# matroxfb_swapped
> > [root@tux root]# fbset -fb /dev/fb0
> >
> > mode "1024x0-1273"
> > # D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
> > geometry 1024 0 1024 0 32
> > timings 15386 160 32 30 4 128 4
> > accel true
> > rgba 8/16,8/8,8/0,8/24
> > endmode
>
> What does 'matroxfb_swapped' do ? You have not only yres_virtual, but also
> yres set to 0. It looks to me like that 'matroxfb_swapped' asked for
> this...
it's swapped from matroxset tarball (see end of mail )
i have to run it in order to have independand heads,
until i run it fb0 is displayed on both fb0 & fb1
<hopeless wish>
is there a way to add an option for independand fb's
without matroxset
</hopeless wish>
> Driver in kernel is identical to driver on my site, except that features
> which are impossible to have with 2.6 fbdev kernel API were removed.
> But for mere users who do not need fbset, different resolutions on each
> display, textual displays or legacy svga games should not notice any
> difference.
> Petr
could the problem be in the different resolutions of fb0 & fb1 ?
everything is OK if i use the default 640x480, the problem shows when
i try "options matroxfb_base vesa=0x117"
fb0 124x768 <-> fb1 640x480
svetljo
[root@tux root]# cat `which matroxfb_swapped `
#! /bin/sh
if [ -c /dev/fb0 ]; then
HEAD0=/dev/fb0
HEAD1=/dev/fb1
else
HEAD0=/dev/fb/0
HEAD1=/dev/fb/1
fi
matroxset -f ${HEAD1} -m 0
matroxset -f ${HEAD0} -m 2
matroxset -f ${HEAD1} -m 1
--
HoHoHo! Seid Ihr auch alle schön brav gewesen?
GMX Weihnachts-Special: Die 1. Adresse für Weihnachts-
männer und -frauen! http://www.gmx.net/de/cgi/specialmail
+++ GMX - die erste Adresse für Mail, Message, More! +++
|
|
From: Petr V. <VAN...@vc...> - 2003-12-01 19:56:20
|
On 1 Dec 03 at 20:27, Svetoslav Slavtchev wrote:
>
> <hopeless wish>
> is there a way to add an option for independand fb's
> without matroxset
> </hopeless wish>
No.
> could the problem be in the different resolutions of fb0 & fb1 ?
> everything is OK if i use the default 640x480, the problem shows when
> i try "options matroxfb_base vesa=0x117"
> fb0 124x768 <-> fb1 640x480
matroxfb_swapped does not touch videomode, so it is really surprising
that it clears yres for you. It only says which CRTC is connected
to which OUTPUT.
Can you do:
fbset -fb /dev/fb0
matroxset -f /dev/fb1 -m 0
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 2
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 0
fbset -fb /dev/fb0
matroxset -f /dev/fb0 -m 1
fbset -fb /dev/fb0
and post output here? I do not see any reason why matroxset should clear
yres/yres_virtual unless you already did not have yres_virtual at zero
before (then it will clip yres to yres_virtual, making it zero too).
Petr
|
|
From: Svetoslav S. <sv...@gm...> - 2003-12-01 20:11:12
|
> On 1 Dec 03 at 20:27, Svetoslav Slavtchev wrote:
> >
> > <hopeless wish>
> > is there a way to add an option for independand fb's
> > without matroxset
> > </hopeless wish>
>
> No.
>
> > could the problem be in the different resolutions of fb0 & fb1 ?
> > everything is OK if i use the default 640x480, the problem shows when
> > i try "options matroxfb_base vesa=0x117"
> > fb0 124x768 <-> fb1 640x480
>
> matroxfb_swapped does not touch videomode, so it is really surprising
> that it clears yres for you. It only says which CRTC is connected
> to which OUTPUT.
>
> Can you do:
>
> fbset -fb /dev/fb0
<output 1>
mode "1024x768-60"
# D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
geometry 1024 768 1024 768 32
timings 15386 160 32 30 4 128 4
accel true
rgba 8/16,8/8,8/0,8/24
endmode
> matroxset -f /dev/fb1 -m 0
> fbset -fb /dev/fb0
<output 2>
mode "1024x0-1273"
# D: 64.994 MHz, H: 48.359 kHz, V: 1272.598 Hz
geometry 1024 0 1024 0 32
timings 15386 160 32 30 4 128 4
accel true
rgba 8/16,8/8,8/0,8/24
endmode
> matroxset -f /dev/fb0 -m 2
> fbset -fb /dev/fb0
<output 2>
> matroxset -f /dev/fb0 -m 0
> fbset -fb /dev/fb0
<output 2>
> matroxset -f /dev/fb0 -m 1
> fbset -fb /dev/fb0
<output 2>
> and post output here? I do not see any reason why matroxset should clear
> yres/yres_virtual unless you already did not have yres_virtual at zero
> before (then it will clip yres to yres_virtual, making it zero too).
svetljo
--
HoHoHo! Seid Ihr auch alle schön brav gewesen?
GMX Weihnachts-Special: Die 1. Adresse für Weihnachts-
männer und -frauen! http://www.gmx.net/de/cgi/specialmail
+++ GMX - die erste Adresse für Mail, Message, More! +++
|
|
From: Svetoslav S. <sv...@gm...> - 2003-12-01 16:57:19
|
> On 1 Dec 03 at 17:02, Svetoslav Slavtchev wrote: > > > > is this a matroxfb bug ? > > Maybe. But I'd say that you broke fbdev API matroxfb expects. theoretically it should be mostly the same as in Linus tree > > > matroxfb: MTRR's turned on > > > matroxfb: 1024x768x16bpp (virtual: 1024x65536) > > > fbcon_startup: res: 1024x0-16 > > Like that you are somewhere truncating values to 16 bits?! Thus 65536 == 0 > in your arithmetic... And as matroxfb's code does > > if (var->yres_virtual > 32767) > var->yres_virtual = 32767; > > it is impossible for yres_virtual to ever become 65536... Besides that > for 1024x65536/16bpp you need 128MB of videoram, and G550 can have only > 32MB. So you screwed something a lot. You should get > > matroxfb: Matrox G550 detected > matroxfb: MTRR's turned on > matroxfb: 1024x768x16bpp (virtual: 1024x8190) > matroxfb: framebuffer at 0xDA000000, mapped to 0xe0810000, size 33554432 > Console: switching to colour frame buffer device 128x48 > fb0: MATROX frame buffer device two questions 1.) is there a way to specify yres_virtual, i can not see such module option 2.) how should one adjust the mode for head2, matroxfb_crtc2 has only a "mem" option > > I'd say that if you want support from me, you should use my code... > I have no idea what you are doing in your tree, but you are apparently > doing wrong things... just asking :( i'm not a kernel programmer, and i'm not familiar with the fb /console internals if i was i would try to merge your driver, but i'm not so ... and as said your driver makes deep changes to the FB API, which IMHO are incompatible with ruby i know i can not ask for support at least until 2.7 is open and ruby merged into it, and even then may be you'll keep your driver out of tree which will complicate support questions may be just asking for pointers whats going wrong, so Aivils or James can fix it best, svetljo -- Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS! Ideal für alle, die gerne MMS verschicken: 25 FreeMMS/Monat mit GMX TopMail. http://www.gmx.net/de/cgi/produktemail +++ GMX - die erste Adresse für Mail, Message, More! +++ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X