Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <geg...@li...> - 2004-05-30 20:00:47
|
Your mail to 'Gegl-developer' with the subject
Re: Re: Document
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
https://lists.XCF.Berkeley.EDU/mailman/confirm/gegl-developer/4f8852bb2e66929236427440c6797da8d515290f
|
|
From: <ce...@ri...> - 2004-05-30 10:04:32
|
lumarga wrote: > Hi everyone, > Excuse-me, I don't know where ask this, then I'm asking here. > The problem: 'Successful ruby setup and a problem -- localhost:1.0 > is destroyed by logging out on localhost:0.0 ' posted by Boszormenyi > Zoltan and Wayne Whitney on March was solved in newer patch's? No, there is no patch for this issue which was discussed specifically to=20 ATI radeon cards. Maybe, Wayne could post his Xfree hack used to restore=20 the display but this should not be relevant to you since you have=20 different hardware. Would you suggest that you experience the same behavior because you have=20 also cards based on an identical graphic chipset ? > My video cards are: Trident Microsystems CyberBlade/i1 (onboard 1:0:0) > and Trident Microsystems TGUI 9440 (rev e3) (0:8:0). > My kernel: Linux slac90 2.4.25-backstreet-ruby > My XFree86: Version 4.3.0 - X Protocol Version 11, Revision 0, > Release 6.6 - patch xf86-430-prefbusid3.diff (from > http://disjunkt.com/dualhead/) > My Display Manager: gdm. Don't know anything particular about Trident cards. You should post=20 configuration and log files to give a good understanding of your setup. >=20 > I'm a bad English writer. You can write me privately in portuguese if it can help. Cheers, C=E9dric |
|
From: Sheena B. <mbg...@te...> - 2004-05-30 05:45:13
|
noise fire play close laugh say arm fallen |
|
From: <ce...@ri...> - 2004-05-29 19:38:02
|
Le lundi 17 Mai 2004 17:59, C=E9dric Rivard a =E9crit : > Hi all, > > I use a kernel version 2.6.5 patched with ruby and have troubles making my > wacom tablet useable. > Every click or touch event throws in XFree logs several lines like that: > wacom: relative event received (0)!!! > wacom: relative event received (1)!!! This issue is not related to the ruby patch because I have similar troubles= =20 with a vanilla 2.6 kernel with or w/o new versions of the wacom driver. It worked smoothly with a 2.4 kernel. I guess I'll have to track this subje= ct=20 specifically to 2.6. Thanks to Svetljo for pointing out this possibility. C=E9dric |
|
From: lumarga <lu...@it...> - 2004-05-28 19:17:49
|
Hi everyone, Excuse-me, I don't know where ask this, then I'm asking here. The problem: 'Successful ruby setup and a problem -- localhost:1.0 is destroyed by logging out on localhost:0.0 ' posted by Boszormenyi Zoltan and Wayne Whitney on March was solved in newer patch's? My video cards are: Trident Microsystems CyberBlade/i1 (onboard 1:0:0) and Trident Microsystems TGUI 9440 (rev e3) (0:8:0). My kernel: Linux slac90 2.4.25-backstreet-ruby My XFree86: Version 4.3.0 - X Protocol Version 11, Revision 0, Release 6.6 - patch xf86-430-prefbusid3.diff (from http://disjunkt.com/dualhead/) My Display Manager: gdm. I'm a bad English writer. Thanks, Celso.Silva |
|
From: Aivils <ai...@un...> - 2004-05-28 09:10:23
|
On Thursday 27 May 2004 19:24, hugo vanwoerkom wrote: > >In practice. > > I think James does not have PC in his held. > > Aivils: > What do you mean by "held"? property > Hugo. I try to tease James. Looks like he works from mainframe in the nuklear bunker floor -15, where sloopy pentagon sysop forgot close outgoing ssh port. I think so, because James do updates only after bug report, but never of itself - so have not a PC :) Aivils |
|
From: Helge H. <hel...@ai...> - 2004-05-28 07:14:47
|
Aivils wrote:
>On Thursday 27 May 2004 15:40, Helge Hafting wrote:
>
>
>>Aivils wrote:
>>
>>
>>
>>>Hi All!
>>>
>>> CVS now contains linux-ruby against 2.6.6.
>>>
>>>FBIOGET_CON2FBMAP, FBIOSET_CON2FBMAP ioctl() uses
>>>dummy call.
>>>
>>>
>>>
>>>
>>Thanks for the good work - ruby-2.6.6 works for me.
>>There is a small problem where I get 998 messages in
>>/var/log/messages during startup.
>>This slows startup down with abouit half a minute,
>>but doesn't seem to have other problems:
>>One run:
>>
>>May 26 22:57:27 monster kernel: Badness in vc_resize at
>>drivers/char/vt.c:1095
>>May 26 22:57:27 monster kernel: Call Trace:
>>May 26 22:57:27 monster kernel: [<c0208ad4>] vc_resize+0x3b4/0x3c0
>>May 26 22:57:27 monster kernel: [<c0128678>] notifier_call_chain+0x18/0x40
>>May 26 22:57:27 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70
>>May 26 22:57:27 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340
>>May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60
>>May 26 22:57:27 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90
>>May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60
>>May 26 22:57:27 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0
>>May 26 22:57:27 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50
>>May 26 22:57:27 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a
>>May 26 22:57:27 monster kernel: [<c0106cff>] syscall_call+0x7/0xb
>>May 26 22:57:28 monster kernel:
>>
>>
>
>
>
>>Then the machine was reset, probably by me.
>>
>>The log then contains a restart followed by about 900 of these
>>vc_restart messages.
>>
>>Could this be a ruby problem, or some sort of framebuffer problem?
>>
>>
>
>ruby needs for tousends of acquire_console_sem();release_console_sem();
>pairs.
>
>Please try this patch, on succes i upload subject on CVS.
>
>
I tested it. It doesn't compile as-is. That seemed to be a
trivial missing pair of curly braces, so I added them.
(See below)
Then it compiled, with the following warnings:
drivers/video/fbmem.c: In function `fb_resize_vt':
drivers/video/fbmem.c:1014: warning: implicit declaration of function
`acquire_console_sem'
drivers/video/fbmem.c:1016: warning: implicit declaration of function
`release_console_sem'
Probably a missing header - it linked and gave me a kernel. It hung, though.
Could this be the problem, or is it a more difficult deadlock issue with
the semaphore?
The kernel hung after initializing the framebuffers, before
setting up fbcon. So all I got was a screenful of pre-fbcon garbage.
It is interesting to note that the first keyboard was dead, it did
not react to "numlock" or sysrq sequences. The second keyboard
was fine, it reacted to numloc/capslock by turning the LEDs on/off
as usual, and I could sync & reboot using sysrq sequences there.
My guess is that this looks like some sort of deadlock. Perhaps the
console semaphore isn't free, or something else needs it?
Do the "printk" that tells us about "160x64 color fbcon takeover"
need the semaphore?
Only one console locked up.
>diff -Nurp ruby-CVS-20040525/drivers/video/console/fbcon.c ruby-CVS-20040527/drivers/video/console/fbcon.c
>--- ruby-CVS-20040525/drivers/video/console/fbcon.c 2004-05-24 21:26:48.000000000 +0300
>+++ ruby-CVS-20040527/drivers/video/console/fbcon.c 2004-05-27 18:06:46.000000000 +0300
>@@ -761,7 +761,9 @@ static void fbcon_set_display(struct vc_
> if (!init) {
>
> if (vc->vc_cols != nr_cols || vc->vc_rows != nr_rows)
>
>
Added a { here
>+ acquire_console_sem();
> vc_resize(vc, nr_cols, nr_rows);
>+ release_console_sem();
>
>
Added a } here. Without these braces I got
a syntax error on the "else" on the next line.
> else if (IS_VISIBLE &&
> vc->vc_mode == KD_TEXT) {
> accel_clear_margins(vc, info, 0);
>@@ -1842,7 +1844,9 @@ static int fbcon_do_set_font(struct vc_d
> && (info->var.yres_virtual % h < info->var.yres % h))
> p->vrows--;
> updatescrollmode(p, vc);
>+ acquire_console_sem();
> vc_resize(vc, info->var.xres / w, info->var.yres / h);
>+ release_console_sem();
> if (IS_VISIBLE && softback_buf) {
> int l = fbcon_softback_size / vc->vc_size_row;
> if (l > 5)
>diff -Nurp ruby-CVS-20040525/drivers/video/fbmem.c ruby-CVS-20040527/drivers/video/fbmem.c
>--- ruby-CVS-20040525/drivers/video/fbmem.c 2004-05-24 21:26:48.000000000 +0300
>+++ ruby-CVS-20040527/drivers/video/fbmem.c 2004-05-27 18:07:10.000000000 +0300
>@@ -1010,8 +1010,11 @@ fb_resize_vt(struct fb_info *info)
> vc = vt->default_mode;
> vc->vc_cols = info->var.xres/vc->vc_font.width;
> vc->vc_rows = info->var.yres/vc->vc_font.height;
>- for(i = 0; i < vt->vc_count; i++)
>+ for(i = 0; i < vt->vc_count; i++) {
>+ acquire_console_sem();
> vc_resize(vt->vc_cons[i], vc->vc_cols, vc->vc_rows);
>+ release_console_sem();
>+ }
> return 0;
> }
>
>
>
I hope this bug report can be of help,
Helge Hafting
|
|
From: hugo v. <hug...@ca...> - 2004-05-27 16:24:28
|
>---- Begin Original Message ---- > >From: Aivils <ai...@un...> >Sent: Wed, 26 May 2004 09:33:36 +0300 >To: <VAN...@vc...>, jsi...@in... >CC: lin...@li... >Subject: Re: Multihead officially dead?! ..... >In practice. >=09I think James does not have PC in his held. Aivils: What do you mean by "held"? Hugo. >=09You keep separate kernel tree typicaly >called =A0"just another kernel >hack from hundreds" :) > >Aivils Stoss The following signature is automatically added by the web email service I use, which is beyond my control: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Support Care2 Email: Stop "scientific" whaling, the whale-killing looph= ole http://www.care2.com/go/z/12803 |
|
From: hugo v. <hug...@ca...> - 2004-05-27 16:24:27
|
>---- Begin Original Message ---- > >From: Aivils <ai...@un...> >Sent: Wed, 26 May 2004 09:33:36 +0300 >To: <VAN...@vc...>, jsi...@in... >CC: lin...@li... >Subject: Re: Multihead officially dead?! ..... >In practice. >=09I think James does not have PC in his held. Aivils: What do you mean by "held"? Hugo. >=09You keep separate kernel tree typicaly >called =A0"just another kernel >hack from hundreds" :) > >Aivils Stoss The following signature is automatically added by the web email service I use, which is beyond my control: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Support Care2 Email: Stop "scientific" whaling, the whale-killing looph= ole http://www.care2.com/go/z/12803 |
|
From: Aivils <ai...@un...> - 2004-05-27 14:26:51
|
On Thursday 27 May 2004 15:40, Helge Hafting wrote:
> Aivils wrote:
>
> >Hi All!
> >
> > CVS now contains linux-ruby against 2.6.6.
> >
> >FBIOGET_CON2FBMAP, FBIOSET_CON2FBMAP ioctl() uses
> >dummy call.
> >
> >
> Thanks for the good work - ruby-2.6.6 works for me.
> There is a small problem where I get 998 messages in
> /var/log/messages during startup.
> This slows startup down with abouit half a minute,
> but doesn't seem to have other problems:
> One run:
>
> May 26 22:57:27 monster kernel: Badness in vc_resize at
> drivers/char/vt.c:1095
> May 26 22:57:27 monster kernel: Call Trace:
> May 26 22:57:27 monster kernel: [<c0208ad4>] vc_resize+0x3b4/0x3c0
> May 26 22:57:27 monster kernel: [<c0128678>] notifier_call_chain+0x18/0x40
> May 26 22:57:27 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70
> May 26 22:57:27 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340
> May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60
> May 26 22:57:27 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90
> May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60
> May 26 22:57:27 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0
> May 26 22:57:27 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50
> May 26 22:57:27 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a
> May 26 22:57:27 monster kernel: [<c0106cff>] syscall_call+0x7/0xb
> May 26 22:57:28 monster kernel:
> Then the machine was reset, probably by me.
>
> The log then contains a restart followed by about 900 of these
> vc_restart messages.
>
> Could this be a ruby problem, or some sort of framebuffer problem?
ruby needs for tousends of acquire_console_sem();release_console_sem();
pairs.
Please try this patch, on succes i upload subject on CVS.
diff -Nurp ruby-CVS-20040525/drivers/video/console/fbcon.c ruby-CVS-20040527/drivers/video/console/fbcon.c
--- ruby-CVS-20040525/drivers/video/console/fbcon.c 2004-05-24 21:26:48.000000000 +0300
+++ ruby-CVS-20040527/drivers/video/console/fbcon.c 2004-05-27 18:06:46.000000000 +0300
@@ -761,7 +761,9 @@ static void fbcon_set_display(struct vc_
if (!init) {
if (vc->vc_cols != nr_cols || vc->vc_rows != nr_rows)
+ acquire_console_sem();
vc_resize(vc, nr_cols, nr_rows);
+ release_console_sem();
else if (IS_VISIBLE &&
vc->vc_mode == KD_TEXT) {
accel_clear_margins(vc, info, 0);
@@ -1842,7 +1844,9 @@ static int fbcon_do_set_font(struct vc_d
&& (info->var.yres_virtual % h < info->var.yres % h))
p->vrows--;
updatescrollmode(p, vc);
+ acquire_console_sem();
vc_resize(vc, info->var.xres / w, info->var.yres / h);
+ release_console_sem();
if (IS_VISIBLE && softback_buf) {
int l = fbcon_softback_size / vc->vc_size_row;
if (l > 5)
diff -Nurp ruby-CVS-20040525/drivers/video/fbmem.c ruby-CVS-20040527/drivers/video/fbmem.c
--- ruby-CVS-20040525/drivers/video/fbmem.c 2004-05-24 21:26:48.000000000 +0300
+++ ruby-CVS-20040527/drivers/video/fbmem.c 2004-05-27 18:07:10.000000000 +0300
@@ -1010,8 +1010,11 @@ fb_resize_vt(struct fb_info *info)
vc = vt->default_mode;
vc->vc_cols = info->var.xres/vc->vc_font.width;
vc->vc_rows = info->var.yres/vc->vc_font.height;
- for(i = 0; i < vt->vc_count; i++)
+ for(i = 0; i < vt->vc_count; i++) {
+ acquire_console_sem();
vc_resize(vt->vc_cons[i], vc->vc_cols, vc->vc_rows);
+ release_console_sem();
+ }
return 0;
}
|
|
From: Helge H. <hel...@ai...> - 2004-05-27 12:38:25
|
Aivils wrote: >Hi All! > > CVS now contains linux-ruby against 2.6.6. > >FBIOGET_CON2FBMAP, FBIOSET_CON2FBMAP ioctl() uses >dummy call. > > Thanks for the good work - ruby-2.6.6 works for me. There is a small problem where I get 998 messages in /var/log/messages during startup. This slows startup down with abouit half a minute, but doesn't seem to have other problems: One run: May 26 22:57:27 monster kernel: Badness in vc_resize at drivers/char/vt.c:1095 May 26 22:57:27 monster kernel: Call Trace: May 26 22:57:27 monster kernel: [<c0208ad4>] vc_resize+0x3b4/0x3c0 May 26 22:57:27 monster kernel: [<c0128678>] notifier_call_chain+0x18/0x40 May 26 22:57:27 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70 May 26 22:57:27 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340 May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:27 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90 May 26 22:57:27 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:27 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0 May 26 22:57:27 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50 May 26 22:57:27 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a May 26 22:57:27 monster kernel: [<c0106cff>] syscall_call+0x7/0xb May 26 22:57:28 monster kernel: The next one appeared twice: May 26 22:57:28 monster kernel: Badness in set_origin at drivers/char/vt.c:503 May 26 22:57:28 monster kernel: Call Trace: May 26 22:57:28 monster kernel: [<c020767c>] set_origin+0x9c/0xb0 May 26 22:57:28 monster kernel: [<c0208970>] vc_resize+0x250/0x3c0 May 26 22:57:28 monster kernel: [<c0128678>] notifier_call_chain+0x18/0x40 May 26 22:57:28 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70 May 26 22:57:28 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0 May 26 22:57:28 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50 May 26 22:57:28 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a May 26 22:57:28 monster kernel: [<c0106cff>] syscall_call+0x7/0xb May 26 22:57:28 monster kernel: May 26 22:57:28 monster kernel: Badness in set_palette at drivers/char/vt.c:291 May 26 22:57:28 monster kernel: Call Trace: May 26 22:57:28 monster kernel: [<c0206e18>] set_palette+0x78/0x80 May 26 22:57:28 monster kernel: [<c0207936>] update_screen+0x36/0x80 May 26 22:57:28 monster kernel: [<c0208a25>] vc_resize+0x305/0x3c0 May 26 22:57:28 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70 May 26 22:57:28 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0 May 26 22:57:28 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50 May 26 22:57:28 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a May 26 22:57:28 monster kernel: [<c0106cff>] syscall_call+0x7/0xb Then I got 31 of these: May 26 22:57:28 monster kernel: Badness in vc_resize at drivers/char/vt.c:1095 May 26 22:57:28 monster kernel: Call Trace: May 26 22:57:28 monster kernel: [<c0208ad4>] vc_resize+0x3b4/0x3c0 May 26 22:57:28 monster kernel: [<c0283999>] fb_resize_vt+0x59/0x70 May 26 22:57:28 monster kernel: [<c0283b17>] fb_ioctl+0x167/0x340 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014aaa9>] exclusive_swap_page+0x39/0x90 May 26 22:57:28 monster kernel: [<c0134391>] unlock_page+0x11/0x60 May 26 22:57:28 monster kernel: [<c014109d>] do_wp_page+0x7d/0x2f0 May 26 22:57:28 monster kernel: [<c014613d>] __pte_chain_free+0x4d/0x50 May 26 22:57:28 monster kernel: [<c015f5dc>] sys_ioctl+0xec/0x25a May 26 22:57:28 monster kernel: [<c0106cff>] syscall_call+0x7/0xb Then the machine was reset, probably by me. The log then contains a restart followed by about 900 of these vc_restart messages. Could this be a ruby problem, or some sort of framebuffer problem? Helge Hafting |
|
From: Petr V. <VAN...@vc...> - 2004-05-26 10:47:50
|
On 26 May 04 at 9:33, Aivils wrote:
> > Hi,
> > I'm looking at '[PATCH] fbdev: mode switching fix.' from
> > 2004/05/22 10:37:52 (it is present in 2.6.7-rc1), and I cannot
> > understand how these changes are supposed to work. Would you mind
> > explaining to me how multihead is supposed to work after these "fixes"?
>
> In abstract.
> Two postulats used by James Simmons
> 1) fbdev print inhuman graphic into hardware video memory.
> 2) fbcon send human friendly graphic primitives to fbdev.
There is also:
3) vt subsystem sends characters to fbcon.
And this step is currently broken, as vt subsystem now passes down
characters only for FOREGROUND console, not for all VISIBLE consoles
(as due to shared master_display_fg there is only one VISIBLE console,
foreground one...).
> Your request breaks 1st postulat, because fbdev must not know
> console status.
Nope. You cannot create abstraction by saying "it is not true that
there is more than one visible console in multihead system". You can
repeat it ad nausea, but I'll still see two (and somebody else can
see three, four... you know).
That 'display_fg' does not have to be in the fbdev structure, it can
be somewhere where fbcon will allocate storage for it, but as there
is 1:1 relation between fb_info and display_fg, it seems logical
(probably only to me...) to stuff it into fb_info.
Ok, I'll release my new patch, as soon as I'll get scrollback
back to work - currently I have none, and it is really annoying...
Petr
|
|
From: Aivils <ai...@un...> - 2004-05-26 06:27:51
|
Hi All! CVS now contains linux-ruby against 2.6.6. FBIOGET_CON2FBMAP, FBIOSET_CON2FBMAP ioctl() uses dummy call. Aivils Stoss |
|
From: Aivils <ai...@un...> - 2004-05-26 05:41:55
|
> Hi, > I'm looking at '[PATCH] fbdev: mode switching fix.' from > 2004/05/22 10:37:52 (it is present in 2.6.7-rc1), and I cannot > understand how these changes are supposed to work. Would you mind > explaining to me how multihead is supposed to work after these "fixes"? > > Long ago, when multihead worked, each head had its own display_fg > variable, which was pointed to by all VCs displayed on that head (through > vc's vc_display_fg pointer). All infrastructure depends on it, namely > IS_VISIBLE and CON_IS_VISIBLE. > > Now that change (without mentioning it in changelog) removed display_fg > from fb_info completely, leaving all VCs pointing to one global > master_display_fg variable. Thus turning my multihead system which could > update two screens at once into system which thinks that it has only > one visible display. > > Are there any plans to fix this behavior and restore multihead support? In abstract. Two postulats used by James Simmons 1) fbdev print inhuman graphic into hardware video memory. 2) fbcon send human friendly graphic primitives to fbdev. Your request breaks 1st postulat, because fbdev must not know console status. In practice. I think James does not have PC in his held. You keep separate kernel tree typicaly called "just another kernel hack from hundreds" :) Aivils Stoss |
|
From: Petr V. <VAN...@vc...> - 2004-05-24 15:22:31
|
Hi,
I'm looking at '[PATCH] fbdev: mode switching fix.' from
2004/05/22 10:37:52 (it is present in 2.6.7-rc1), and I cannot
understand how these changes are supposed to work. Would you mind
explaining to me how multihead is supposed to work after these "fixes"?
Long ago, when multihead worked, each head had its own display_fg
variable, which was pointed to by all VCs displayed on that head (through
vc's vc_display_fg pointer). All infrastructure depends on it, namely
IS_VISIBLE and CON_IS_VISIBLE.
Now that change (without mentioning it in changelog) removed display_fg
from fb_info completely, leaving all VCs pointing to one global
master_display_fg variable. Thus turning my multihead system which could
update two screens at once into system which thinks that it has only
one visible display.
Are there any plans to fix this behavior and restore multihead support?
Thanks,
Petr Vandrovec
|
|
From: Aivils <ai...@un...> - 2004-05-24 07:01:43
|
On Tuesday 18 May 2004 21:57, James Simmons wrote: > > Hi folks!!! > > For July 19 and 20th I will be attending the Desktop Summit as > well as the kernel summit. The kernel summit is unfortunely by > invitation only :-( but the desktop one is open to the public. To the > people that have worked hard on this project let me know if you want to go > to the desktop summit. If you don't have the money I will work something > out for you. These summits befall over sea! > I plan to give a demo of Ruby there!!!! So in the next few > weeks I'm going to set up a box to send to the conference. Current CVS contain ugly VGA driver (?) bug - tty1 cursor lost positon after vt switch. I have no idea where that bug lives. You must patch or hide with fbdev. gpm - Your tree breaks (/dev/vc/0) . /dev/vcs* - I don't know how to use it, rather that is broken. > My goals for the demo are to have a 4 desktop system. 4 desktop system, seems, well tested is Nvidia adapters only, with closed source drivers. I agree usage of easy sytems, where each user have soundcard too. Sound setup is hard, because each program use own sound driver. > I like to get KDE > running on one desktop and Gnome on another. gdm allow choose session. Most psyhodelic is full screen vmware session with lovely M$ inside. > Then the other 2 heads would > be a Embedded JVM running and a regular console. xf86 stops VGA output. looks like PC legacy ports used for VGA stoping. This feature does not distrub starting number of xf86 and i never try locate it. Of course ruby needs for good "marketing manager" , which tell anybody about benefits of ruby. Aivils |
|
From: Petr V. <van...@vc...> - 2004-05-23 16:00:38
|
On Sun, May 23, 2004 at 05:08:46PM +0200, Helge Hafting wrote:
> On Fri, May 21, 2004 at 01:29:24PM +0200, Petr Vandrovec wrote:
> > On 21 May 04 at 12:18, Helge Hafting wrote:
> >
> > > Still, it'd be nice to have an option (specified on the kernel command
> > > line or the module.conf file) that allows overriding this.
> > >
> > > Something like matrox:outputs:xyz
> > > x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing.
> > > The first position(x) then correspond to the primary output, the second(y)
> > > the secondary output, and the third(z) DVI.
> > >
> > > The default then, when not sepcified, would be matrox:outputs:111
> > > which is your default with CRTC1 everywhere.
> >
> > Yes. It looks reasonable.
> >
> > > Are you interested in supporting such an option? I can try to make a
> > > patch myself if you aren't interested in developing it yourself.
> >
> > I started working on it, but then I made 'bk pull' and found that
> > fbcon changed a bit and that I have to adapt my infrastructure to get
> > it back to work (as with stock fbcon I cannot drive my system in a
> > way I want :-( ).
>
> Here is a patch that works for my G550.
> It probably needs some polishing, and more work in order to
> work with other cards than G550 / G450. It is meant for testing by anybody
> interested.
>
> Still, it works on my G550, the kernel parameter video=matrox:outputs:21
> connects CRTC2 to the first plug and CRTC1 to the second plug.
> outputs:11 is the default if the parameter is omitted.
>
>
> The first position is the first plug, the second position is
> the second plug. I didn't figure out any third output.
>
> Specifying 0 connects nothing to that plug.
> Specifying 1 connects CRTC1, and 2 connects CRTC2. Other values
> won't work and the default of 1 will be used instead.
Ah. I sent my patch to linux-fbdev-devel, not to the linuxconsole-dev... (and to the
ak...@os...). Patch included below.
I'm quite surprised that your change works for 'outputs:21' without changing matroxfb_DAC1064.c
sources...
It should work same way as your patch did, except that it accepts three digits, and it
should work for modular matroxfb too.
Petr
Date: Sun, 23 May 2004 14:03:08 +0200
From: Petr Vandrovec <van...@vc...>
To: ak...@os...
Cc: lin...@li...
Subject: [PATCH] matroxfb: Add support for mapping CRTC<->outputs at boot time
Hi Andrew,
some people expressed interest in having possibility to set CRTC <-> outputs mapping
at boot time, without having to use 'matroxset' later after kernel boots.
This patch adds option 'video=matroxfb:outputs:XYZ', where X sets which CRTC will connect
to primary output, Y sets secondary output and Z sets DVI output.
In addition to that I also added missing memset() into maven, which was broken since
i2c was kobjectified.
I have no idea what you'll do with 'Signed-off-by' line below, but just in case, this
patch was written entirely by me, and I'm not aware about any other IP or patents pending
on it.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <van...@vc...>
diff -urdN linux/drivers/video/matrox/matroxfb_DAC1064.c linux/drivers/video/matrox/matroxfb_DAC1064.c
--- linux/drivers/video/matrox/matroxfb_DAC1064.c 2004-05-22 18:38:19.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_DAC1064.c 2004-05-23 13:04:23.000000000 +0200
@@ -660,7 +660,7 @@
ACCESS_FBINFO(features.accel.has_cacheflush) = 1;
ACCESS_FBINFO(outputs[0]).output = &m1064;
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
@@ -859,7 +859,7 @@
{
ACCESS_FBINFO(outputs[0]).output = &m1064;
}
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
diff -urdN linux/drivers/video/matrox/matroxfb_Ti3026.c linux/drivers/video/matrox/matroxfb_Ti3026.c
--- linux/drivers/video/matrox/matroxfb_Ti3026.c 2004-05-22 18:38:01.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_Ti3026.c 2004-05-23 13:03:08.000000000 +0200
@@ -692,7 +692,7 @@
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).output = &ti3026_output;
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
if (ACCESS_FBINFO(devflags.noinit))
diff -urdN linux/drivers/video/matrox/matroxfb_base.c linux/drivers/video/matrox/matroxfb_base.c
--- linux/drivers/video/matrox/matroxfb_base.c 2004-05-22 18:38:28.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_base.c 2004-05-23 13:08:04.000000000 +0200
@@ -1272,6 +1272,7 @@
static int dfp; /* "matrox:dfp */
static int dfp_type = -1; /* "matrox:dfp:xxx */
static int memtype = -1; /* "matrox:memtype:xxx" */
+static char outputs[8]; /* "matrox:outputs:xxx" */
#ifndef MODULE
static char videomode[64]; /* "matrox:mode:xxxxx" or "matrox:xxxxx" */
@@ -1537,6 +1538,39 @@
static int hotplug = 0;
+static void setDefaultOutputs(WPMINFO2) {
+ unsigned int i;
+ const char* ptr;
+
+ ACCESS_FBINFO(outputs[0]).default_src = MATROXFB_SRC_CRTC1;
+ if (ACCESS_FBINFO(devflags.g450dac)) {
+ ACCESS_FBINFO(outputs[1]).default_src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[2]).default_src = MATROXFB_SRC_CRTC1;
+ } else if (dfp) {
+ ACCESS_FBINFO(outputs[2]).default_src = MATROXFB_SRC_CRTC1;
+ }
+ ptr = outputs;
+ for (i = 0; i < MATROXFB_MAX_OUTPUTS; i++) {
+ char c = *ptr++;
+
+ if (c == 0) {
+ break;
+ }
+ if (c == '0') {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_NONE;
+ } else if (c == '1') {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_CRTC1;
+ } else if (c == '2' && ACCESS_FBINFO(devflags.crtc2)) {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_CRTC2;
+ } else {
+ printk(KERN_ERR "matroxfb: Unknown outputs setting\n");
+ break;
+ }
+ }
+ /* Nullify this option for subsequent adapters */
+ outputs[0] = 0;
+}
+
static int initMatrox2(WPMINFO struct board* b){
unsigned long ctrlptr_phys = 0;
unsigned long video_base_phys = 0;
@@ -1577,20 +1611,18 @@
ACCESS_FBINFO(devflags.crtc2) = (b->flags & DEVF_CRTC2) != 0;
ACCESS_FBINFO(devflags.maven_capable) = (b->flags & DEVF_MAVEN_CAPABLE) != 0;
ACCESS_FBINFO(devflags.dualhead) = (b->flags & DEVF_DUALHEAD) != 0;
+ ACCESS_FBINFO(devflags.dfp_type) = dfp_type;
+ ACCESS_FBINFO(devflags.g450dac) = (b->flags & DEVF_G450DAC) != 0;
+ ACCESS_FBINFO(devflags.textstep) = ACCESS_FBINFO(devflags.vgastep) * ACCESS_FBINFO(devflags.textmode);
+ ACCESS_FBINFO(devflags.textvram) = 65536 / ACCESS_FBINFO(devflags.textmode);
+ setDefaultOutputs(PMINFO2);
if (b->flags & DEVF_PANELLINK_CAPABLE) {
ACCESS_FBINFO(outputs[2]).data = MINFO;
ACCESS_FBINFO(outputs[2]).output = &panellink_output;
- if (dfp)
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_CRTC1;
- else
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_NONE;
+ ACCESS_FBINFO(outputs[2]).src = ACCESS_FBINFO(outputs[2]).default_src;
ACCESS_FBINFO(outputs[2]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
ACCESS_FBINFO(devflags.panellink) = 1;
}
- ACCESS_FBINFO(devflags.dfp_type) = dfp_type;
- ACCESS_FBINFO(devflags.g450dac) = (b->flags & DEVF_G450DAC) != 0;
- ACCESS_FBINFO(devflags.textstep) = ACCESS_FBINFO(devflags.vgastep) * ACCESS_FBINFO(devflags.textmode);
- ACCESS_FBINFO(devflags.textvram) = 65536 / ACCESS_FBINFO(devflags.textmode);
if (ACCESS_FBINFO(capable.cross4MB) < 0)
ACCESS_FBINFO(capable.cross4MB) = b->flags & DEVF_CROSS4MB;
@@ -1813,6 +1845,13 @@
to yres_virtual * xres_virtual < 2^32 */
}
matroxfb_init_fix(PMINFO2);
+ /* Normalize values (namely yres_virtual) */
+ matroxfb_check_var(&vesafb_defined, &ACCESS_FBINFO(fbcon));
+ /* And put it into "current" var. Do NOT program hardware yet, or we'll not take over
+ * vgacon correctly. fbcon_startup will call fb_set_par for us, WITHOUT check_var,
+ * and unfortunately it will do it BEFORE vgacon contents is saved, so it won't work
+ * anyway. But we at least tried... */
+ ACCESS_FBINFO(fbcon.var) = vesafb_defined;
err = -EINVAL;
printk(KERN_INFO "matroxfb: %dx%dx%dbpp (virtual: %dx%d)\n",
@@ -1834,6 +1873,9 @@
* until someone tells me what is proper thing to do */
printk(KERN_INFO "fb%d: initializing hardware\n",
ACCESS_FBINFO(fbcon.node));
+ /* We have to use FB_ACTIVATE_FORCE, as we had to put vesafb_defined to the fbcon.var
+ * already before, so register_framebuffer works correctly. */
+ vesafb_defined.activate |= FB_ACTIVATE_FORCE;
fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
}
return 0;
@@ -2012,7 +2054,7 @@
init_waitqueue_head(&ACCESS_FBINFO(crtc1.vsync.wait));
init_waitqueue_head(&ACCESS_FBINFO(crtc2.vsync.wait));
ACCESS_FBINFO(crtc1.panpos) = -1;
-
+
err = initMatrox2(PMINFO b);
if (!err) {
#ifndef CONFIG_FB_MATROX_MULTIHEAD
@@ -2288,6 +2330,8 @@
mem = simple_strtoul(this_opt+4, NULL, 0);
else if (!strncmp(this_opt, "mode:", 5))
strlcpy(videomode, this_opt+5, sizeof(videomode));
+ else if (!strncmp(this_opt, "outputs:", 8))
+ strlcpy(outputs, this_opt+8, sizeof(outputs));
else if (!strncmp(this_opt, "dfp:", 4)) {
dfp_type = simple_strtoul(this_opt+4, NULL, 0);
dfp = 1;
@@ -2463,6 +2507,8 @@
MODULE_PARM_DESC(dfp, "Specifies whether to use digital flat panel interface of G200/G400 (0 or 1) (default=0)");
MODULE_PARM(dfp_type, "i");
MODULE_PARM_DESC(dfp_type, "Specifies DFP interface type (0 to 255) (default=read from hardware)");
+MODULE_PARM(outputs, "c8");
+MODULE_PARM_DESC(outputs, "Specifies which CRTC is mapped to which output (string of up to three letters, consisting of 0 (disabled), 1 (CRTC1), 2 (CRTC2)) (default=111 for Gx50, 101 for G200/G400 with DFP, and 100 for all other devices)");
#ifdef CONFIG_PPC_PMAC
MODULE_PARM(vmode, "i");
MODULE_PARM_DESC(vmode, "Specify the vmode mode number that should be used (640x480 default)");
diff -urdN linux/drivers/video/matrox/matroxfb_base.h linux/drivers/video/matrox/matroxfb_base.h
--- linux/drivers/video/matrox/matroxfb_base.h 2004-05-22 18:38:21.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_base.h 2004-05-22 19:15:15.000000000 +0200
@@ -479,6 +479,7 @@
struct matrox_altout* output;
void* data;
unsigned int mode;
+ unsigned int default_src;
} outputs[MATROXFB_MAX_OUTPUTS];
#define MATROXFB_MAX_FB_DRIVERS 5
diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
--- linux/drivers/video/matrox/matroxfb_crtc2.c 2004-05-22 18:38:33.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_crtc2.c 2004-05-23 13:05:47.000000000 +0200
@@ -628,15 +628,6 @@
m2info->mmio.vbase = ACCESS_FBINFO(mmio.vbase);
m2info->mmio.len = ACCESS_FBINFO(mmio.len);
- /*
- * If we have unused output, connect CRTC2 to it...
- */
- if (ACCESS_FBINFO(outputs[1]).output &&
- ACCESS_FBINFO(outputs[1]).src == MATROXFB_SRC_NONE &&
- ACCESS_FBINFO(outputs[2]).src == MATROXFB_SRC_NONE) {
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;
- }
-
matroxfb_dh_init_fix(m2info);
if (register_framebuffer(&m2info->fbcon)) {
return -ENXIO;
diff -urdN linux/drivers/video/matrox/matroxfb_g450.c linux/drivers/video/matrox/matroxfb_g450.c
--- linux/drivers/video/matrox/matroxfb_g450.c 2004-05-22 18:38:33.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_g450.c 2004-05-22 20:05:43.000000000 +0200
@@ -591,11 +591,11 @@
if (ACCESS_FBINFO(devflags.g450dac)) {
down_write(&ACCESS_FBINFO(altout.lock));
tvo_fill_defaults(PMINFO2);
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[1]).src = ACCESS_FBINFO(outputs[1]).default_src;
ACCESS_FBINFO(outputs[1]).data = MINFO;
ACCESS_FBINFO(outputs[1]).output = &matroxfb_g450_altout;
ACCESS_FBINFO(outputs[1]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[2]).src = ACCESS_FBINFO(outputs[2]).default_src;
ACCESS_FBINFO(outputs[2]).data = MINFO;
ACCESS_FBINFO(outputs[2]).output = &matroxfb_g450_dvi;
ACCESS_FBINFO(outputs[2]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
diff -urdN linux/drivers/video/matrox/matroxfb_maven.c linux/drivers/video/matrox/matroxfb_maven.c
--- linux/drivers/video/matrox/matroxfb_maven.c 2004-05-22 18:37:59.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_maven.c 2004-05-22 20:05:04.000000000 +0200
@@ -1188,7 +1188,7 @@
md->client = clnt;
down_write(&ACCESS_FBINFO(altout.lock));
ACCESS_FBINFO(outputs[1]).output = &maven_altout;
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_NONE;
+ ACCESS_FBINFO(outputs[1]).src = ACCESS_FBINFO(outputs[1]).default_src;
ACCESS_FBINFO(outputs[1]).data = md;
ACCESS_FBINFO(outputs[1]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
up_write(&ACCESS_FBINFO(altout.lock));
@@ -1249,6 +1249,7 @@
err = -ENOMEM;
goto ERROR0;
}
+ memset(new_client, 0, sizeof(*new_client) + sizeof(*data));
data = (struct maven_data*)(new_client + 1);
i2c_set_clientdata(new_client, data);
new_client->addr = address;
|
|
From: Helge H. <hel...@ai...> - 2004-05-23 15:06:39
|
On Fri, May 21, 2004 at 01:29:24PM +0200, Petr Vandrovec wrote: > On 21 May 04 at 12:18, Helge Hafting wrote: > > > Still, it'd be nice to have an option (specified on the kernel command > > line or the module.conf file) that allows overriding this. > > > > Something like matrox:outputs:xyz > > x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing. > > The first position(x) then correspond to the primary output, the second(y) > > the secondary output, and the third(z) DVI. > > > > The default then, when not sepcified, would be matrox:outputs:111 > > which is your default with CRTC1 everywhere. > > Yes. It looks reasonable. > > > Are you interested in supporting such an option? I can try to make a > > patch myself if you aren't interested in developing it yourself. > > I started working on it, but then I made 'bk pull' and found that > fbcon changed a bit and that I have to adapt my infrastructure to get > it back to work (as with stock fbcon I cannot drive my system in a > way I want :-( ). Here is a patch that works for my G550. It probably needs some polishing, and more work in order to work with other cards than G550 / G450. It is meant for testing by anybody interested. Still, it works on my G550, the kernel parameter video=matrox:outputs:21 connects CRTC2 to the first plug and CRTC1 to the second plug. outputs:11 is the default if the parameter is omitted. The first position is the first plug, the second position is the second plug. I didn't figure out any third output. Specifying 0 connects nothing to that plug. Specifying 1 connects CRTC1, and 2 connects CRTC2. Other values won't work and the default of 1 will be used instead. Helge Hafting |
|
From: Daniel L. <dan...@ya...> - 2004-05-22 22:45:44
|
Hi, I thought someone might like to know that with Svetljo's great patience and assistance (thank you yet again) I have managed to get my first Ruby working. The configuration is: - PCI ATI Radeon 7000 32MB (Sapphire) - PCI Matrox Millenium I 4MB I start X0 on the Radeon, and then open a konsole window to start X1 on the Matrox. I can reliably stop and restart X1 without problems. I haven't tried stopping and starting X0 from X1 yet. These 2 worked with the SingleCard option in my XF86Config-4 file. I couldn't get them working with PrefBusID option, and didn't try the hackvideo thing. I've noticed a few problems that I haven't solved yet... 1) Keyboard autorepeat doesn't work once I start X1. 2) I have a three PCI Radeon 7000 cards. I can't seem to find a combination where any 2 or 3 of these cards will be happy together. Generally whenever I try and start a second of them, the system locks up, screens go blank (but not into power saving mode), and caps/scroll/num lock fail to have any effect. One day I'll have 3 cards working all with DRI... in my dreams... Regards, Dan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.688 / Virus Database: 449 - Release Date: 18/05/2004 |
|
From: Kjetil K. <kj...@kj...> - 2004-05-21 20:22:43
|
On onsdag 19. mai 2004, 10:12, Svetoslav Slavtchev wrote: > > Well, the dual-head config didn't work when I installed the new > > binaries, I guess there could be a reason for it... :-) > > can you explain a bit more? > what do you think is the reason? Uhm, found it.... I needed to prefix the BusIDs with "PCI:"... The really bad thing is that I understood that from reading the patch a couple of weeks ago, but seeing it blow up in my face erased it from my mind, and so I went around screaming in terror instead of trying to use my brain... :-) That's life I guess... But since I didn't have that before, and it worked, it is perhaps a Debian-specific note for the HOWTO? Also, I'm running on two different cards, which means, I shouldn't use SingleCard, right? Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kj...@kj... web...@sk... ed...@le... Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC |
|
From: James v. Z. <ja...@dv...> - 2004-05-21 13:07:23
|
Haven't tried this just yet, from what I've read the source tree is very similar and I am expecting the patch may apply with little modification? FC2 ( and others apparently ) has switched to x.org over XFree86's licencing decisions on their most recent release. Has anyone tried applying the prefbusid patch to current X.org? J |
|
From: Petr V. <VAN...@vc...> - 2004-05-21 11:35:40
|
On 21 May 04 at 12:18, Helge Hafting wrote:
> Still, it'd be nice to have an option (specified on the kernel command
> line or the module.conf file) that allows overriding this.
>
> Something like matrox:outputs:xyz
> x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing.
> The first position(x) then correspond to the primary output, the second(y)
> the secondary output, and the third(z) DVI.
>
> The default then, when not sepcified, would be matrox:outputs:111
> which is your default with CRTC1 everywhere.
Yes. It looks reasonable.
> Are you interested in supporting such an option? I can try to make a
> patch myself if you aren't interested in developing it yourself.
I started working on it, but then I made 'bk pull' and found that
fbcon changed a bit and that I have to adapt my infrastructure to get
it back to work (as with stock fbcon I cannot drive my system in a
way I want :-( ).
Petr Vandrovec
|
|
From: Helge H. <hel...@ai...> - 2004-05-21 10:16:37
|
Petr Vandrovec wrote: >On 19 May 04 at 13:40, Svetoslav Slavtchev wrote: > > >>>On 19 May 04 at 13:16, Svetoslav Slavtchev wrote: >>> >>> >>>>and it would be nicer to not need matroxset in order >>>>to get two independant fbcon on G550 >>>> >>>> >>>It would need sensing card outputs to find which outputs have connected >>>monitor and which do not, and as there is no doc... >>> >>> >>> >>isn't it possible to simply assume that both outputs >>have connected monitors ? >>or does the driver need to retrive monitor data, >>in order to setup properly ? >> >> > >Problem is that "analog" (HD15) output on G550 is actually >secondary output. So you have to do: > >nothing on DVI/nothing on HD15: anything -> primary output, > anything -> secondary output, > anything -> DVI output, >nothing on DVI/monitor on HD15: anything -> primary output, > CRTC1 -> secondary output, > anything -> DVI output, >analog monitor on DVI/nothing on HD15: CRTC1 -> primary output, > anything -> secondary output, > anything -> DVI output, >digital monitor on DVI/nothing on HD15:anything -> primary output, > anything -> secondary output, > CRTC1 -> DVI output, >analog monitor on DVI/monitor on HD15: CRTC1 -> primary output > CRTC2 -> secondary output > anything -> DVI output, >digital monitor on DVI/monitor on HD15:anything -> primary output, > CRTC2 -> secondary output, > CRTC1 -> DVI output, > > >As you can see, you can put CRTC2 to the secondary output only if >monitors are connected to both outputs (or at least if primary output >has monitor connected). If you'll put CRTC2 on secondary output >unconditionally, you do not support (only) analog monitor connected >to analog G550 output... > >Moreover, user may want CRTC2 on primary output and CRTC1 on secondary >(if his first monitor is analog one). And you cannot make this >config default too, as it would not work with TV-Out: user would >have primary display on TV then, and it is probably not what user >had in the mind. > >So I still think that CRTC1 on all three outputs is configuration >which satisfies most of the users. > Petr Vandrovec > > > Thank you for explaining this. I agree that CRTC1 everywhere is a good default. Still, it'd be nice to have an option (specified on the kernel command line or the module.conf file) that allows overriding this. Something like matrox:outputs:xyz x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing. The first position(x) then correspond to the primary output, the second(y) the secondary output, and the third(z) DVI. The default then, when not sepcified, would be matrox:outputs:111 which is your default with CRTC1 everywhere. I have my primary analog monitor on the analog output (this is the one output the BIOS uses) which you call secondary. My other analog monitor is connected to the DVI plug using the DVI->VGA converter supplied with the card. I guess my setup then, would be matrox:outputs:012 to get CRTC1 on the secondary and CRTC2 on the DVI. (or possibly matrox:outputs:210 if the stuff I get from that converter really is the primary out, rather than DVI out converted to analog. I don't know how this converter works.) Are you interested in supporting such an option? I can try to make a patch myself if you aren't interested in developing it yourself. Helge Hafting |
|
From: Zoltan B. <zb...@fr...> - 2004-05-20 17:44:21
|
James Simmons =EDrta: >>Will you tell them about Zolt=E1n B=F6sz=F6rm=E9nyi's double 3D setup t= oo? :-) >=20 >=20 > Yes. Great! :-) Do you need more details about the machine setup? I suppose you put your presentation somewhere after Desktop summit. Will you post the link to this list, too? BTW I will try to do the same under x86_64 FC2 soon. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: TJ <tre...@li...> - 2004-05-19 21:31:18
|
Hi,
I was looking into letting the X server be happy no matter when
the mouse is pluged in (before or after it is started) or even
unplugged and plugged in again.
If you tell the server layout about a good handfull of mice
/dev/input/mouse[0..9] for example
InputDevice "VoidMouse" "CorePointer"
InputDevice "Mouse0"
InputDevice "Mouse1"
InputDevice "Mouse2"
you can use xsetpointer to switch to the mouse for your screen
eg use a hotplug script.
so when you plug a mouse in, hotplug will use xsetpointer for
appropriate display to switch to the mouse
(use the "void" input driver when no mouse, and probably
as the the core mouse in config, and switch to correct mouse
if its available once running)
Now all this works fine in theory, bar one problem i'd like some
help on. X only looks at what inputdevices are available:
- When it starts
- When you switch to and then from the console (ctrl+alt+f#)
so switching to a mouse that was plugged in after these event
(in this case xsetpointer will only see it if you allowmouseopenfail)
is no good it dont move, unless you do a console switch afterwards.
XListInputDevices() as use by xsetpointer will not show devices that
failed to open at the two times (as said above) when X looks, unless
you use the AllowMouseOpenFail option
XOpenDevice() seem to stay quiet when you open a device, while useing
AllowMouseOpenFail and the device was not there last check, it doesn't
even bother looking again =/
It obvious to me that underlaying design of XF can tolerate inputdevices
coming and going, what i been looking for is some function call, or code that
will cause X to recheck what input devices it has on demand, not just in the
two case above.
inside the XFree86 binary there is this code
from: xc/programs/Xserver/hw/xfree86/common/xf86Init.c InitInput()
...
pInfo = xf86InputDevs;
while (pInfo) {
xf86ActivateDevice(pInfo);
pInfo = pInfo->next;
}
...
which i think is whats needed, but these symbols are not available out side of
it. I am not a strong enough coder at the mo and would like help tampering with
it. also i not yet found a way to connect gdb to an X running on some machine
as it, without nasty things happening.
(yes I know about evdev, humor me if you can help)
Thank you.
Thorben
PS Although I am not on this list, I do read it via the gmane news
gateway (in knode if you care) so you dont need to cc me.
|
1998 messages has been excluded from this view by a project administrator.
