linuxconsole-dev

Re: ruby possible bugs

[James S. <jsi...@tr...>]

> Hi , James
>=20
> I see You commit inna "ruby" and "linux-dj" very suspicios code.
>=20
> It looks as:
> linux-dj vgacon.c
> for(i=3D0; i<MAX_NR_CONSOLES; i++) {
>  =A0 =A0 =A0 =A0struct vc_data *c =3D vt_cons->vc_cons[i];

 Yeap. Looks broken. BTW ruby doesn't boot for vgacon. I have todebug it
tonight.

> ruby   keyboard.c
> /* enable receieving key events for each VC */
> for (i =3D 0; i < MAX_NR_USER_CONSOLES; i++)
>      vt->vc_cons[i]->vc_kam =3D 1;
>=20
>=20
> This one guaranted oops kernel under ruby,
> because only one VC per VT inicialized by default.



> linux-dj vgacon.c will be tested under ruby tomorrow.

Will not compile. Struct consw has changed for ruby.
=20
> IMHO in all cycles You must add condition if(vt->vc_cons[i]) { ... }
> or move routines in vc_allocate() ;-)

Yes. I plan to fix it. RIght now I'm fixing the fbcon alyer. It is really
broken.

Re: Participate?

[James S. <jsi...@tr...>]

> I'm the current maintainer of Linux Console Tools (adopted them from Yann
> Dirson), so I would really like to participate in the new linux console
> framework development, and also improve lct accordingly.

Great!! I need the help since I'm lagging behind.

> First questions are obvious -- is there a todo list? The things that I would
> be personally interested in are per-VC font/keymaps support and improving
> Unicode support. What is the status of these and what has to be done?

I such post a todo list. I do have per-VC fot support. I still haven't
figured a clean way to deal with VC switch tho. No per VC keymaps. The
unicode needs to be redone. I plan to change the screen buffer layout for
VCs. To move away from VGA centric layout to something that can work with
unicode and support as many fonts as needed. Have any ideas about what the 
screen buffer layout should be?

P.S
  If you want CVS access email me your sourceforge account name.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Alexander R. <ale...@us...>]

Hi,


On Monday 18 March 2002 13:37, you wrote:
> Alexander Rawass wrote:
> > Hi,
> >
> > I am having problems with my system, running kernel-2.4.17 with Johanns
> > iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
> >
> > Sometimes, I am getting such errors:
> >
> > Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
> > Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> > Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>
> > This bug also seems to happen only, when the joystick isn't switched on
> > on startup/driver installation?
>
> I am puzzled  ?-/

This definetely happens only when the joystick is switched off at boot/driver 
install time.

When It's on - everything's fine.

When it's off - kmail goes kaboom when closing a window.

See attachments for dmesg output.





Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: How to do it ?

[svetljo <ga...@st...>]

Hi

>>I've tested Rage128 32Mb RAM (AGP), Riva TNT2 M64 32Mb (PCI), Matrox
>>G550DH 32Mb (AGP) and SiS 6326 8Mb (PCI)
>>for me it works only with the last two in case SiS is primary and G550
>>is secodary,
>>with any other combination starting the second X server frezes the
>>first, exiting the second server brings back the first X server
>>
>
>Similar results.
>
>>i couldn't start the G550DH and the Riva TNT2 as secodary cards with
>>plain X driver
>>there were no errors , but simply a blank screen
>>so i have to use the enchanced driver by Matrox
>>
>
>I think, "nv" driver is suck. Useful for stand alone nvidia.
>Secondary nvidia must have drivers from ftp.nvidia.com .
>
that may be true, but there is no other way in case  you have other 
graphic card
you can not use Nvidia's glx with XFree's glx and DRI for the 2nd card
you can use Nvidia's glx lib (that meens driver too AFAIK) if you have 
only Nvidia's cards

>
>>could you get DRI working on both cards ?
>>
>
>Tested only basic functinality. I try understand dri in future.
>
i've asked only wether acording to the Xlogs  DRI was enabled for both cards
and what was saying glxinfo about DRI and was it direct or indirect 
rendering

>
>Yesternigth I borrow second TNT2 from friend.
>Work for me: two X servers, both could use GLX accelerated apps.
>Harware:
>TNT2 M64 (AGP), TNT2 M64 (PCI).
>two ps/2 keyboards, two serial mice.
>Software:
>X 4.2.0 patched
>kernel 2.4.18 patched with my own "ruby" version.
>nvidia binary drivers 1.0-1541, 1.0-2313 , both works fine.
>
may be i should try it too, which one was your primary card

>
>Games tested: Linux native Quake2 v3.20, Linux native Kingpin v1.20
>Games performance: With my Celeron366 perfomance is suck.
>If two games started feeling like Pentium 120.
>fps don't take, gonna sleep.
>
>
>
>XFree 4.2.0 patch, created without yucking self-commented C code
>understanding.
>May have security holes and bugs.
>
can you explain me what does this patch, does it prevent the second 
instance of X  to disable the PCI and MEM access for the first instance

i've met exactly the same code
on the net-bsd mailing list topic "multiuser XFree-4.1"
http://mail-index.netbsd.org/port-i386/2001/09/05/0000.html

>
>--- xf86pciBus.c.org     Fri Nov 30 12:11:55 2001
>+++ xf86pciBus.c    Thu Mar 21 20:28:21 2002
>@@ -584,9 +584,11 @@
> #ifdef DEBUG
>     ErrorF("pciIoAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
> #endif
>+#if 0
>     ((pciArg*)arg)->ctrl &= ~SETBITS;
>     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
>                ((pciArg*)arg)->ctrl);
>+#endif
> }
>
> #undef SETBITS
>@@ -608,9 +610,11 @@
> #ifdef DEBUG
>     ErrorF("pciIo_MemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
> #endif
>+#if 0
>     ((pciArg*)arg)->ctrl &= ~SETBITS;
>     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
>                ((pciArg*)arg)->ctrl);
>+#endif
> }
>
> #undef SETBITS
>@@ -632,9 +636,11 @@
> #ifdef DEBUG
>     ErrorF("pciMemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
> #endif
>+#if 0
>     ((pciArg*)arg)->ctrl &= ~SETBITS;
>     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
>                ((pciArg*)arg)->ctrl);
>+#endif
> }
> #undef SETBITS
>

and one last question,but don't take it too seriously :)
could you please send a diff/patch from vanila-2.4.18 to your kernel or 
only the ruby-part
thanks a lot in advance

svetljo

ruby possible bugs

[Aivils S. <Aiv...@un...>]

Hi , James

I see You commit inna "ruby" and "linux-dj" very suspicios code.

It looks as:
linux-dj vgacon.c
for(i=3D0; i<MAX_NR_CONSOLES; i++) {
 =A0 =A0 =A0 =A0struct vc_data *c =3D vt_cons->vc_cons[i];

ruby   keyboard.c
/* enable receieving key events for each VC */
for (i =3D 0; i < MAX_NR_USER_CONSOLES; i++)
     vt->vc_cons[i]->vc_kam =3D 1;


This one guaranted oops kernel under ruby,
because only one VC per VT inicialized by default.

linux-dj vgacon.c will be tested under ruby tomorrow.

IMHO in all cycles You must add condition if(vt->vc_cons[i]) { ... }
or move routines in vc_allocate() ;-)

Aivils Stoss=

Querying available input devices

[Johann D. <jo...@do...>]

Hi,

It is often the case that games need to know the list of joysticks 
available on the system.
Currently, I see two ways of getting this information from userland:
- Try to open each /dev/input/{event,js,mouse,whatever}* and use ioctls 
to check who's there
- Enable hotplug and make /sbin/hotplug to store this information somewhere

The first solution does not look too appealing to me (and that's an 
understatement)
The second seems a bit complicated to use, especially as it involves a 
demon that might need to be modified.

Another issue is the unplug-replug one:
1 Game starts and opens /dev/input/js0 which handles a USB stick
2 USB stick gets unplugged
3 Game receives -ENODEV while trying to read, closes /dev/input/js0
4 USB stick gets replugged into the same slot
5 Game detects it and re-opens it
...

How could 4 be realised ? The only solution I see is for the game to be 
somehow signaled by a hotplug demon (could be done without using 
signals, by polling a file, for example).

Wouldn't it be simpler to use a /proc-based interface, instead of 
emulating it with a demon. Is hotplug designed to handle these situations ?

-- 
Johann Deneux

Re: How to do it ?

[Aivils S. <Aiv...@un...>]

Hi

>i've tested Rage128 32Mb RAM (AGP), Riva TNT2 M64 32Mb (PCI), Matrox
>G550DH 32Mb (AGP) and SiS 6326 8Mb (PCI)
>for me it works only with the last two in case SiS is primary and G550
>is secodary,
> with any other combination starting the second X server frezes the
>first, exiting the second server brings back the first X server

Similar results.

>i couldn't start the G550DH and the Riva TNT2 as secodary cards with
> plain X driver
>there were no errors , but simply a blank screen
>so i have to use the enchanced driver by Matrox

I think, "nv" driver is suck. Useful for stand alone nvidia.
Secondary nvidia must have drivers from ftp.nvidia.com .

>could you get DRI working on both cards ?

Tested only basic functinality. I try understand dri in future.

Yesternigth I borrow second TNT2 from friend.
Work for me: two X servers, both could use GLX accelerated apps.
Harware:
TNT2 M64 (AGP), TNT2 M64 (PCI).
two ps/2 keyboards, two serial mice.
Software:
X 4.2.0 patched
kernel 2.4.18 patched with my own "ruby" version.
nvidia binary drivers 1.0-1541, 1.0-2313 , both works fine.



Games tested: Linux native Quake2 v3.20, Linux native Kingpin v1.20
Games performance: With my Celeron366 perfomance is suck.
If two games started feeling like Pentium 120.
fps don't take, gonna sleep.



XFree 4.2.0 patch, created without yucking self-commented C code
understanding.
May have security holes and bugs.
--- xf86pciBus.c.org     Fri Nov 30 12:11:55 2001
+++ xf86pciBus.c    Thu Mar 21 20:28:21 2002
@@ -584,9 +584,11 @@
 #ifdef DEBUG
     ErrorF("pciIoAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }

 #undef SETBITS
@@ -608,9 +610,11 @@
 #ifdef DEBUG
     ErrorF("pciIo_MemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }

 #undef SETBITS
@@ -632,9 +636,11 @@
 #ifdef DEBUG
     ErrorF("pciMemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }
 #undef SETBITS






Aivils Stoss

Participate?

[Wartan H. <wa...@so...>]

Hello.

I'm the current maintainer of Linux Console Tools (adopted them from Yann
Dirson), so I would really like to participate in the new linux console
framework development, and also improve lct accordingly.

First questions are obvious -- is there a todo list? The things that I would
be personally interested in are per-VC font/keymaps support and improving
Unicode support. What is the status of these and what has to be done?

--
Regards, Wartan.

Re: How to do it ?

[Aivils S. <Aiv...@un...>]

Hi
     In my end to day work simultaneous:
Voodoo Graphic/ Voodoo 3 (PCI).
Voodoo Graphic must be started first.
X 4.1.0 standard.
ruby 2.5.2
x86 system.

Tested Voodoo Graphic / Voodoo 3 (PCI) / TNT2 (AGP). All others two video
card combinations failed.
IMHO X couldt'n stop glide2x. Why, don't know.
If I run X over neighboured console, my first VGA allways freeze by X.
So I try out to remove pci access disabling of X.

Aivils Stoss

Re: How to do it ?

[svetljo <ga...@st...>]

>
>
>>in *xc/programs/Xserver/hw/xfree86/common/xf86Config.c* in the 
>>configDevice function we record the busid of the card from the config 
>>file in a global var and in 
>>*/xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c* in the 
>>*FindPCIVideoInfo* whe jump over the initalizations if the card does not 
>>match the one in our global, this seems to work for now. We are now able 
>>to start several servers without interference
>>
>
>Cool. I've never managed this because of exactly this problem. Do you
>have a patch available? I'd like to try it myself.
>
sadly i don't have it  and i couldn't find one
i've found 2 cards that cooperate

>>Now this is of course a monumental kludge, so could somone who has a 
>>good grasp of the inards and secrets of the PCI stuff please lend us a 
>>hand ?
>>
>
>Try asking Egbert Eich (ei...@su...), he's an expert in that.
>
>>We think it should work is as follows:
>>
>>Dont touch cards not mentioned in the config file period. :-)
>>
>
>It's a problem because of legacy port mappings. Some cards need those to
>initialize, and for two cards they'll overlap.
>
>>http://village.flashnet.it/users/fn048069/multiuser.html
>>
>
(from http://mail-index.netbsd.org/port-i386/2001/09/  topic *multiuser 
X 4.1.0 <http://mail-index.netbsd.org/port-i386/2001/09/10/0016.html>* )
but i was wondering what does this code do :

--- xf86pciBus.c	Fri Aug 10 12:15:44 2001
+++ /tmp/xf86pciBus.c	Tue Sep  4 17:02:01 2001
@@ -534,9 +534,11 @@
 #ifdef DEBUG
     ErrorF("pciIoAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
 			 ((pciArg*)arg)->ctrl);
+#endif
 }
 
 #undef SETBITS
@@ -558,9 +560,11 @@
 #ifdef DEBUG
     ErrorF("pciIo_MemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
 			 ((pciArg*)arg)->ctrl);
+#endif
 }
 
 #undef SETBITS
@@ -582,9 +586,11 @@
 #ifdef DEBUG
     ErrorF("pciMemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
 			 ((pciArg*)arg)->ctrl);
+#endif
 }
 #undef SETBITS
 
@@ -3141,4 +3147,3 @@
     else
 	pciWriteLong(tag, PCI_CMD_STAT_REG, temp & ~PCI_CMD_MASTER_ENABLE);
 }

Re: How to do it ?

[Vojtech P. <vo...@su...>]

On Mon, Feb 25, 2002 at 05:47:46PM +0100, svetljo wrote:
> We have been trying to get several xervers running at the same time.
> 
> We have applied the patches to disable the VT handling + home grown ones 
> to handle keyboard and mouse events, but there is still something funny 
> going on:
> 
> For each server server started, the previous ones will stop their 
> output. stopping the servers in the reverse order will also enable the 
> previous server again!

> After some late nights and much head scratching we found what we 
> consider a severe misfeature: when X starts up it will scan the PCI bus 
> for all cards, collecting all video cards and promplty call 
> DisablePciAccess for each card, even tough the card is not mentioned in 
> the config file, this will disable all output to for anny previously 
> started servers, it does not look like the previous xserver is aware of 
> this, it continues running, no error messages, and if we start a test 
> program it will continue running. Stopping the last server wil 
> "reenable" the previous one as if nothing had happened.
> 
> We have come up with the following hack:
> 
> in *xc/programs/Xserver/hw/xfree86/common/xf86Config.c* in the 
> configDevice function we record the busid of the card from the config 
> file in a global var and in 
> */xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c* in the 
> *FindPCIVideoInfo* whe jump over the initalizations if the card does not 
> match the one in our global, this seems to work for now. We are now able 
> to start several servers without interference

Cool. I've never managed this because of exactly this problem. Do you
have a patch available? I'd like to try it myself.

> Now this is of course a monumental kludge, so could somone who has a 
> good grasp of the inards and secrets of the PCI stuff please lend us a 
> hand ?

Try asking Egbert Eich (ei...@su...), he's an expert in that.

> We think it should work is as follows:
> 
> Dont touch cards not mentioned in the config file period. :-)

It's a problem because of legacy port mappings. Some cards need those to
initialize, and for two cards they'll overlap.

> http://village.flashnet.it/users/fn048069/multiuser.html
> 
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
> /
> 
> /Date: Wed, 27 Jun 2001 15:56:01 -0700 (PDT) From: Mark Vojkovich To: 
> Kim Lilliestierna cc: xpert mailing list Subject: Re: [Xpert]Problems 
> with multi x servers
> 
> On Thu, 28 Jun 2001, Kim Lilliestierna wrote:
> 
>  > We think it should work is as follows: > > Dont touch cards not 
> mentioned in the config file period. :-) >
> 
> You have to. If they are both vga cards and the X-server is trying to 
> run the one that isn't the primary head, you have to disable I/O access 
> to the primary card and enable for the secondary card instead. VGA cards 
> share resources. The only reason why you get graphics at all after you 
> boot up with multiple cards is because the bios disabled all but one of 
> them.
> 
> A single server can run multiple VGA cards similtaneously because it 
> mediates access to them, putting them on and pulling them off of the bus 
> when appropriate.
> 
> I believe the XFree86 RAC code only does this pulling and putting when 
> necessary (ie, only when there are resource conflicts).
> 
> /
> 
> /
> /
> /
> ------------------------------------------------------------------------
> / /
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

-- 
Vojtech Pavlik
SuSE Labs

Re: [Libff-devel] Re: Support for Logitech Cordless rumble pad added

[Vojtech P. <vo...@su...>]

On Mon, Mar 11, 2002 at 09:55:00AM +0100, Johann Deneux wrote:
> Vojtech Pavlik wrote:
> > On Thu, Mar 07, 2002 at 12:16:36AM +0100, Johann Deneux wrote:
> > 
> >>Hi,
> >>
> >>I've just committed a few changes to the hid code. Few changes on the 
> >>existing files, most of the code is situated in the newly added hid-ff.c 
> >>file.
> >>
> >>Please have a look at these files and make comments on the way I chose 
> >>to leave room for other force-feedback protocol implementations.
> >>
> >>I also copied the Makefile and Config.* files from kernel 2.5.5-dj1. As 
> >>those files had last been touched when kernel 2.5.1 went out, I guess 
> >>the parts that were missing from the files in the CVS tree were 
> >>additions we missed (and not removal done on purpose).
> >>
> > 
> > Hmm, just wondering - why did you do things differently than the
> > hiddev/hid-input stuff already in there? Btw, I'm considering to
> 
> What do you mean ? I see obvious differences (these objects don't do the 
> same thing), but beside that, they look quite similar to me. They add 
> their specific data hook to hid (input, hiddev, ff_private). I also add 
> a few function hooks (ff_exit, ff_event) that I could move to 
> ff_private. That's the biggest difference I see. Was that the one you 
> had in mind ?

I meant that you could use the same bitfield for the CLAIMED stuff, etc.
However, considering that you still need the hid-imput code for the
hid-ff, which means things have to be a little different.

Second thoughts, I think it's pretty much OK.

> > modularize the stuff completely, making hiddev, hid-input, and hid-ff
> > separate modules ...

> Yes, I also wondered if I should make hid-ff a module of his own. I can 
> see that I will probably need to split hid-ff when new protocols are 
> added, but I am not sure this means it should be a module of his own.
> I understand that each driver should be compilable as a module, but what
> are the rules to decide if a multi-part driver should be split into several
> modules ?
> 
> I foresee one difficulty: hid and hid-ff need to register to the input
> layer at the same time. Isn't it simpler then to leave them as one
> multi-part driver ?

Probably it is. I'd like to merge the wacom driver in later as well,
because it really *uses* HID, although for a very specific purpose of
encapsulating its own serial protocol ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Xlib errors

[<jg...@pa...>]

Typically, this happens when the request stream gets corrupted.
The X server keeps track of how many requests it has seen and returns this
sequence number in replies.

This can happen a number of ways:
	1) multithreaded application not using locking properly (Xlib has
	locking for MT use, but you have to turn it on).
	2) memory trashing bug
	3) Xlib or X server error.
	4) some corruption in the data stream between the X server and client.

3) and 4) is quite rare: I'd suspect 1 or 2 to start, until proven otherwise.
			- Jim


--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg...@pa...

Re: [Vegastrike-devel] Xlib errors

[Johann D. <jo...@do...>]

Alexander Rawass wrote:
> Hi,
> 
> I am having problems with my system, running kernel-2.4.17 with Johanns 
> iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
> 
> Sometimes, I am getting such errors:
> 
> Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x87!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x86!
> Xlib: sequence lost (0x175bb > 0x76fa) in reply type 0x12! 
> Xlib: sequence lost (0x10700 > 0x7e8) in reply type 0x1c!
> Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
> Xlib: sequence lost (0x103ff > 0x880) in reply type 0x0!
> Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
> Xlib: unexpected async reply (sequence 0x89f)!
> Xlib: sequence lost (0x30c56 > 0x20d31) in reply type 0x1c!
> 

"unexpected async replies" happen when multi-threaded applications use 
multiple threads to communicate with X.
I don't know about the lost sequences.

> The application I use (kmail,galeon) quits (without me wanting it), but the 
> window stays there, frozen.
> 
> This seems mostly to happen to kmail-1.3.1/KDE-2.2 and also
> galeon-0.12 using gtk1.2/gnome-1.4.0.2 when a sub-window closes.
> 

That could be it, if the sub-window is handled by a concurrent thread.

> This doesn't seem to happen with konsole,xemacs
> 
> Are there any reported problems with XFree4.0.2/kernel-2.4.17 ?
> 
> I don't think that it has got to do anything with the iforce patch, but maybe 
> you have run into such problems with newer kernels??
> 

I ran into such problems a long time ago, even with 2.0.x kernels. I 
don't think the kernel is responsible, but I may be wrong.

> With kernel-2.4.2, that stuff didn't happen.
> 
> I've not yet tried kernel-2.4.17 without iforce-patch, I had not yet the time 
> to apply Johanns latest patch.

I don't think my latest patch would correct this.

> 
> This bug also seems to happen only, when the joystick isn't switched on on 
> startup/driver installation?
>

I am puzzled  ?-/

-- 
Johann Deneux

Xlib errors

[Alexander R. <ale...@us...>]

Hi,

I am having problems with my system, running kernel-2.4.17 with Johanns 
iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:

Sometimes, I am getting such errors:

Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x87!
Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x86!
Xlib: sequence lost (0x175bb > 0x76fa) in reply type 0x12! 
Xlib: sequence lost (0x10700 > 0x7e8) in reply type 0x1c!
Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
Xlib: sequence lost (0x103ff > 0x880) in reply type 0x0!
Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
Xlib: unexpected async reply (sequence 0x89f)!
Xlib: sequence lost (0x30c56 > 0x20d31) in reply type 0x1c!

The application I use (kmail,galeon) quits (without me wanting it), but the 
window stays there, frozen.

This seems mostly to happen to kmail-1.3.1/KDE-2.2 and also
galeon-0.12 using gtk1.2/gnome-1.4.0.2 when a sub-window closes.

This doesn't seem to happen with konsole,xemacs

Are there any reported problems with XFree4.0.2/kernel-2.4.17 ?

I don't think that it has got to do anything with the iforce patch, but maybe 
you have run into such problems with newer kernels??

With kernel-2.4.2, that stuff didn't happen.

I've not yet tried kernel-2.4.17 without iforce-patch, I had not yet the time 
to apply Johanns latest patch.

This bug also seems to happen only, when the joystick isn't switched on on 
startup/driver installation?



Alex
 
-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Lost of updates!!!

[James S. <jsi...@tr...>]

Hi folks!!

	As you can see not only have we synced up to 2.5.5 I have made a
bunch of changes to support many platforms. I still need to update the
fbdev drivers. 

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: Ruby and linux-dj difference

[Aivils S. <Aiv...@un...>]

> > complete_console_change() allow overlapped video, but vt_map_input() is
> > designed for separate non-overlapped video units. I think, if root run
X
> > over neighbourhood console, then start console must remain unchanged. I
add
> > for test kdev_same() chek in VT_RELDISP (vt_ioctl.c), but this don't
help
> > me , because X freeze VGA any way.
>
> Hm. I will have to test that. In theory you shouldn't be able to run X on
> a different VT than the one you are on.

I realy need run X on a different VT. This trick allow me run two X servers
simultaneous. I use Virtual frame buffer as second VT, because 2D
accelerated
framebuffers are multihead enemy. IMHO XFree need videoless dumb console VT
only to serve keyboard for (second, third, ...) X server.
Current I could run first XFree on Voodoo Graphic with "glide" driver
and second XFree on Voodoo3 (PCI) "tdfx" without interference.
Both X have separate keyboards and mice.
All other video hardware combinations failed.
Standard X 4.1.0 used.
X applications used for pastime !!!

> > After manipulation with neighbourhood console kernel sametimes die in
> > keyboard.c function kbd_keycode() tag L_ECHO(tty) , because
tty->termios
> > == null . I add condition !(tty->termios) and its work for me.
>
> Strange. Termios gets blown away. I will have to look at the tty layer.

Die keypress sequence:
Alt-F1; Alt up; Alt long down (will repeat).
IMHO X disallocate /dev/tty0.

> > vgacon.c to day has nasty bug. Your patch 6 weeks ago is incomplete.
> > vc->display_fg is unicialized and oops kernel.
> > I was to lazy download and test.
>
> Hm. Will try it ou once I have it compile. I really need to get time to
> rewrite the vga driver.

Patch for impatient X users.
--- vgacon.c.org        Wed Jan 30 19:25:03 2002
+++ vgacon.c    Fri Mar 15 10:05:32 2002
@@ -487,6 +487,7 @@
        }
        vgacon_state.mode = MODE_TEXT;

+       vc->display_fg = vt;
        vt->data_hook = (void *) &vgacon_state;

        if (init) {



I hope special Midnight Commander symbols will be back
in near future.


WHY YOU TRY STOP KEYBOARD EVENT STREAM???
IMHO keyboard.c v1.73 are unusable.
Usable is only v1.71 without vc_kam processing.

Safe place for vc->vc_kam = 1; is vc_allocate() (file vt.c).
Safe VC output stop is in function do_con_write() (file vt.c) after
calling terminal_emulation(). Not till then You can switch on/off
vc->vc_kam with special keys and Alt-Fx still work for VC switch
(kam are separate for each VC).


Aivils Stoss

Re: [SYNC] 2.5.5

[Vojtech P. <vo...@su...>]

On Thu, Mar 14, 2002 at 02:52:31PM -0800, James Simmons wrote:

> We are now synced to Linus's 2.5.5 tree. It does not compile due to non
> ruby related issues. I recommend that people use the dave jones tree. It
> actually compiles and works. I haven't tried the CVS over the dj tree yet. 
> 
> Vojtech due to the sound system changes I guess a few joysticks drivers
> need to be updates their. Could you handle that?

Yes, sure.

-- 
Vojtech Pavlik
SuSE Labs

Re: Ruby and linux-dj difference

[James S. <jsi...@tr...>]

> Hi
>      Has  linux-dj old school vt-manager or new with multi keyboard
> support?

Almost but it is not their just yet.

> complete_console_change() allow overlapped video, but vt_map_input() is
> designed for separate non-overlapped video units. I think, if root run X
> over neighbourhood console, then start console must remain unchanged. I add
> for test kdev_same() chek in VT_RELDISP (vt_ioctl.c), but this don't help
> me , because X freeze VGA any way.

Hm. I will have to test that. In theory you shouldn't be able to run X on
a different VT than the one you are on.
 
> After manipulation with neighbourhood console kernel sametimes die in
> keyboard.c function kbd_keycode() tag L_ECHO(tty) , because tty->termios
> == null . I add condition !(tty->termios) and its work for me.

Strange. Termios gets blown away. I will have to look at the tty layer.

> vgacon.c to day has nasty bug. Your patch 6 weeks ago is incomplete.
> vc->display_fg is unicialized and oops kernel.
> I was to lazy download and test.

Hm. Will try it ou once I have it compile. I really need to get time to
rewrite the vga driver.

> All about AGAINST-2.5.2

Now against 2.5.5 :-)

[SYNC] 2.5.5

[James S. <jsi...@tr...>]

We are now synced to Linus's 2.5.5 tree. It does not compile due to non
ruby related issues. I recommend that people use the dave jones tree. It
actually compiles and works. I haven't tried the CVS over the dj tree yet. 

Vojtech due to the sound system changes I guess a few joysticks drivers
need to be updates their. Could you handle that?

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Ruby and linux-dj difference

[Aivils S. <Aiv...@un...>]

Hi
     Has  linux-dj old school vt-manager or new with multi keyboard
support?

I test ruby and get same functions is to flexible.

complete_console_change() allow overlapped video, but vt_map_input() is
designed for separate non-overlapped video units. I think, if root run X
over neighbourhood console, then start console must remain unchanged. I add
for test kdev_same() chek in VT_RELDISP (vt_ioctl.c), but this don't help
me , because X freeze VGA any way.

After manipulation with neighbourhood console kernel sametimes die in
keyboard.c function kbd_keycode() tag L_ECHO(tty) , because tty->termios
== null . I add condition !(tty->termios) and its work for me.

vgacon.c to day has nasty bug. Your patch 6 weeks ago is incomplete.
vc->display_fg is unicialized and oops kernel.
I was to lazy download and test.

All about AGAINST-2.5.2

Aivils Stoss
unwearying user

Re: Ruby on PPC, which tree ?

[James S. <jsi...@tr...>]

> Hello all,
> 
> I was wondering what was the current status of Ruby on PowerPC, is it
> known (not) to work ATM ? I haven't tried it in a while, sorry :-(

No problem.I haven't really worked on it in a while. Been busy pushing
stuff into the DJ tree. I plan to sync ruby up to the latest stuff very
soon. 

> Also, what is the "official" tree when working on Ruby ? I'd like to
> resume work on the ruby-fied pm3fb (the old-fashioned one is now
> integrated as of 2.4.19-pre1). For some reason, I believed the DJ tree
> was the one, but it doesn't compile on my box (stuff totally unrelated
> to input or FB). I didn't try any other 2.5.x.

I bet it was the sysrq changes. I sent a patch to fix that. Also I
discovered 64 bit platforms have their own ioctls for certain console
things. Defintely use the DJ tree. It works and it hasall the stuff that
is in ruby. 

Re: [Libff-devel] Re: Support for Logitech Cordless rumble pad added

[Johann D. <jo...@do...>]

Vojtech Pavlik wrote:
> On Thu, Mar 07, 2002 at 12:16:36AM +0100, Johann Deneux wrote:
> 
>>Hi,
>>
>>I've just committed a few changes to the hid code. Few changes on the 
>>existing files, most of the code is situated in the newly added hid-ff.c 
>>file.
>>
>>Please have a look at these files and make comments on the way I chose 
>>to leave room for other force-feedback protocol implementations.
>>
>>I also copied the Makefile and Config.* files from kernel 2.5.5-dj1. As 
>>those files had last been touched when kernel 2.5.1 went out, I guess 
>>the parts that were missing from the files in the CVS tree were 
>>additions we missed (and not removal done on purpose).
>>
> 
> Hmm, just wondering - why did you do things differently than the
> hiddev/hid-input stuff already in there? Btw, I'm considering to

What do you mean ? I see obvious differences (these objects don't do the 
same thing), but beside that, they look quite similar to me. They add 
their specific data hook to hid (input, hiddev, ff_private). I also add 
a few function hooks (ff_exit, ff_event) that I could move to 
ff_private. That's the biggest difference I see. Was that the one you 
had in mind ?

> modularize the stuff completely, making hiddev, hid-input, and hid-ff
> separate modules ...
> 

Yes, I also wondered if I should make hid-ff a module of his own. I can 
see that I will probably need to split hid-ff when new protocols are 
added, but I am not sure this means it should be a module of his own.
I understand that each driver should be compilable as a module, but what
are the rules to decide if a multi-part driver should be split into several
modules ?

I foresee one difficulty: hid and hid-ff need to register to the input
layer at the same time. Isn't it simpler then to leave them as one
multi-part driver ?


-- 
Johann Deneux

ns558 in kernel 2.4.12 and above

[Alexander R. <ale...@us...>]

Hi,

On Sunday 10 March 2002 19:14, you wrote:
> On Sat, Mar 02, 2002 at 11:21:40PM +0100, Alexander Rawass wrote:
> > What has stopped working is my old-analogue joystick:
> >
> > [root@jungle /root]# modprobe ns558
> >
> > I'll hope I'll be able to update on 2.4.17 soon.
>
> In 2.4.12 you shouldn't need the ns558 module anymore, the functionality
> to register a gameport is included in es1371 already. What does 'dmesg'

Ah - I didn't know that.

Then you should update the documentation on the kernel?

I had a look at 2.4.17-iforce, and there it says in
 Documentation/input/joystick.txt

--->
2.4 Modules needed
~~~~~~~~~~~~~~~~~~
  For all joystick drivers to function, you'll need the userland interface
module in kernel, either loaded or compiled in:
 
        modprobe joydev
 
  For gameport joysticks, you'll have to load the gameport driver as well;
 
        modprobe ns558
<----

That's a bit misleading, if you don't need ns588 any more

> say?

I'll try it.


Alex
n
-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: Support for Logitech Cordless rumble pad added

[Vojtech P. <vo...@su...>]

On Thu, Mar 07, 2002 at 12:16:36AM +0100, Johann Deneux wrote:
> Hi,
> 
> I've just committed a few changes to the hid code. Few changes on the 
> existing files, most of the code is situated in the newly added hid-ff.c 
> file.
> 
> Please have a look at these files and make comments on the way I chose 
> to leave room for other force-feedback protocol implementations.
> 
> I also copied the Makefile and Config.* files from kernel 2.5.5-dj1. As 
> those files had last been touched when kernel 2.5.1 went out, I guess 
> the parts that were missing from the files in the CVS tree were 
> additions we missed (and not removal done on purpose).

Hmm, just wondering - why did you do things differently than the
hiddev/hid-input stuff already in there? Btw, I'm considering to
modularize the stuff completely, making hiddev, hid-input, and hid-ff
separate modules ...

-- 
Vojtech Pavlik
SuSE Labs