linuxconsole-dev

Re: CVS Tags

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

> Hello,

> I was just trying to out ruby against an older kernel, when I realized
> that we don't keep proper tags for kernel versions.. I've since gone
> through and tagged everything. Available tags are:

Oops. I forgot to tag them especially since I skipped 2.4.11. Don't use
2.4.11. It is a bad tree from Linus. I just tagged the current tree:

linux_2_4_14

I tets it and it works. Now to break things again.
 

CVS Tags

[Paul M. <pm...@mv...>]

Hello,

I was just trying to out ruby against an older kernel, when I realized
that we don't keep proper tags for kernel versions.. I've since gone
through and tagged everything. Available tags are:

=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=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
File: Makefile         	Status: Up-to-date

   Working revision:	1.40
   Repository revision:	1.40	/cvsroot/linuxconsole/ruby/linux/Makefile,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

   Existing Tags:
	linux_2_4_13             	(revision: 1.39)
	linux_2_4_12             	(revision: 1.38)
	linux_2_4_10             	(revision: 1.37)
	linux_2_4_9              	(revision: 1.36)
	linux_2_4_8              	(revision: 1.34)
	linux_2_4_7              	(revision: 1.31)
	linux_2_4_6              	(revision: 1.30)
	linux_2_4_5              	(revision: 1.26)
	linux_2_4_4              	(revision: 1.25)
	linux_2_4_3              	(revision: 1.24)
	linux_2_4_2              	(revision: 1.23)
	linux_2_4_1              	(revision: 1.22)
	linux_2_4_0              	(revision: 1.21)
	linux_2_4_0_test12       	(revision: 1.20)
	linux_2_4_0_test11       	(revision: 1.19)
	linux_2_4_0_test10       	(revision: 1.18)
	linux_2_4_0_test9        	(revision: 1.17)
	linux_2_4_0_test8        	(revision: 1.16)
	linux_2_4_0_test7        	(revision: 1.15)
	linux_2_4_0_test6        	(revision: 1.14)
	linux_2_4_0_test5        	(revision: 1.13)
	linux_2_4_0_test4        	(revision: 1.12)
	linux_2_4_0_test4_pre3   	(revision: 1.12)
	linux_2_4_0_test2        	(revision: 1.10)
	linux_2_4_0_test2_pre2   	(revision: 1.9)
	linux_2_4_0_test2_pre1   	(revision: 1.8)
	linux_2_4_0_test1        	(revision: 1.8)
	linux_2_3_99_pre9        	(revision: 1.6)
	linux_2_3_99_pre6        	(revision: 1.5)
	linux_2_3_99_pre5        	(revision: 1.4)
	linux_2_3_99_pre4        	(revision: 1.3)
	linux_2_3_99_pre3        	(revision: 1.2)
	iforce-split             	(branch: 1.37.2)

A snapshot of ruby for kernel version can be retrieved via
cvs co -r tag ruby.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: New serial problem?

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

> Theoritically. When I first tried the 2.4.x kernels, PNP support failed
> to initialize my network card. That's why I stuck to isapnp.

Ah. I see.

> > kernel. The serial device you have is PNP?
> 
> It's a joystick. So normally, you plug it in, and then you play ;)
> Seriously, I must admit I have no idea. What does it mean for such a
> device to be PNP ? It should answer to some "standard" query by a
> vendor/product id ?

Plug-and-play (PnP) is a system which automatically detects PC devices
such as disks, sound cards, ethernet cards, modems, etc.  It also does
some low-level configuring of them.  To be detected by PnP, the device
must be designed for PnP.  Non-PnP devices (or PnP devices which have
been correctly PnP-configured), can often be detected by non-PnP
methods.

(no subject)

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

Hi!

   As some of you know I have been working on a new console system for
2.5.X. Now that 2.5.X is very very close I really like to work together
with various people from various trees to pull this together. The two
biggest changes I have done is:

1) A new fbdev api with is much simpler and allows fbdev devices to exist
   without a console system. Nice for embedded devices.

2) We also will be moving the various input devices including keyboards
   over to the input api. 

3) Also I plan to work on a new serial api based on Russell King's work to
   work nicely with the input layer. The serial layer will be more like
   the parallel port layer.

So what I need is the latest drivers from people so they can be ported
over. I also want to know what people needed for the fbdev layer as well
as the input layer. I see some email about DDC support for example. Please
let me know what you need. Thank you. 

Re: Synced to 2.4.14

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

> I'm recovering from a HDD crash, but will be finally getting around 
> to messing with it after I'm up.... been lurking on this list for a few 
> months, but haven't attempted to do much as of yet..
> 
> So.... you have one more tester *grins*

Great. Alot of work is ahead of us. I really like to start porting more
fbdev drivers over. I think I will be placing mor eof them in CVS.
Understand they will be gradually coverted over so they will be broken for
some time. 

Re: ns558.c ans isapnp

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

I applied various fixes to this file. It now compiles. Now I might of
applied the wrong fix but it does work. Vojtech?

Re: Synced to 2.4.14

[<twi...@su...>]

On 13 Nov 2001, at 12:30, James Simmons wrote:
> 
> Okay folks. We are at 2.4.14 now. Yeah!! I tested the code including 
> the new  serial code. It boots and works. Even the new serial code
> works. Yeah!!! Now we need more testers.  

I'm recovering from a HDD crash, but will be finally getting around 
to messing with it after I'm up.... been lurking on this list for a few 
months, but haven't attempted to do much as of yet..

So.... you have one more tester *grins*

James Gibson

James Gibson
twi...@su...

ns558.c ans isapnp

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

Hi,

From ruby/linux/drivers/input/ns558.c, line 172:
#define NS558_DEVICE(a,b,c,d)\
        card_vendor: ISAPNP_ANY_ID, card_device: ISAPNP_ANY_ID,\
        vendor: ISAPNP_VENDOR(a,b,c), device: ISAPNP_DEVICE(d)


static struct isapnp_device_id pnp_devids[] = {
        { NS558_DEVICE('@','P','@',0x0001) }, /* ALS 100 */
        { NS558_DEVICE('@','P','@',0x0020) }, /* ALS 200 */
...

The problem is that the isapnp_device in my 2.4.12 kernel is defined as
follows (from include/linux/isapnp.h line 159):
struct isapnp_device_id {
        unsigned short card_vendor, card_device;
        unsigned short vendor, function;
        unsigned long driver_data;      /* data private to the driver */
};

There is no device field.
Any idea about the fix ?

-- 
Johann Deneux

Re: New serial problem?

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

On Tue, 13 Nov 2001, James Simmons wrote:

> 
> > > Johann did you enable PNP support when you tried out the new serial code?
> > > 
> > No, I am still using the isapnp tools.
> 
> You don't need isapnp tools for 2.4 if you enable PNP support in the

Theoritically. When I first tried the 2.4.x kernels, PNP support failed
to initialize my network card. That's why I stuck to isapnp.

> kernel. The serial device you have is PNP?

It's a joystick. So normally, you plug it in, and then you play ;)
Seriously, I must admit I have no idea. What does it mean for such a
device to be PNP ? It should answer to some "standard" query by a
vendor/product id ?

-- 
Johann Deneux

Re: New serial problem?

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

> > Johann did you enable PNP support when you tried out the new serial code?
> > 
> No, I am still using the isapnp tools.

You don't need isapnp tools for 2.4 if you enable PNP support in the
kernel. The serial device you have is PNP?

Re: New serial problem?

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

On Tue, 13 Nov 2001, James Simmons wrote:

> 
> Johann did you enable PNP support when you tried out the new serial code?
> 
No, I am still using the isapnp tools.

-- 
Johann Deneux

Synced to 2.4.14

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

Okay folks. We are at 2.4.14 now. Yeah!! I tested the code including  the
new  serial code. It boots and works. Even the new serial code works.
Yeah!!! Now we need more testers.  

New serial problem?

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

Johann did you enable PNP support when you tried out the new serial code?

Re: Sourceforge project

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

> > Hm. Does anyone here want to actually use it?
> > 
> 
> I doubt it, even so, I think everyone here prefers the mailing lists.  If
> there is a need for a more user-oriented "forum", then we should create a
> 'linuxconsole-user' or 'linuxconsole-help' mailing list.
> 
> <opinion>Forums are just another example of SourceForge piling on more crud
> to their exterior interface, creating duplication where none is
> needed</opinion> :P

Okay so everyone okay with not using it. 

Re: Sourceforge project

[M. R. B. <mr...@0x...>]

* James Simmons <jsi...@tr...> on Tue, Nov 13, 2001:

>=20
> > I think we should either keep an eye on those, leave messages to redire=
ct
> > people to this mailing list, or close these forums.
> > Leaving this part abandonned may make people think the project is also
> > abandonned.
>=20
> Hm. Does anyone here want to actually use it?
>=20

I doubt it, even so, I think everyone here prefers the mailing lists.  If
there is a need for a more user-oriented "forum", then we should create a
'linuxconsole-user' or 'linuxconsole-help' mailing list.

<opinion>Forums are just another example of SourceForge piling on more crud
to their exterior interface, creating duplication where none is
needed</opinion> :P

M. R.

Re: Sourceforge project

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

> I think we should either keep an eye on those, leave messages to redirect
> people to this mailing list, or close these forums.
> Leaving this part abandonned may make people think the project is also
> abandonned.

Hm. Does anyone here want to actually use it?

> Another point is that perhaps we should release the input-part of the
> project using the File List feature. Indeed, all the input stuff looks
> pretty stable, and should be already fairly usable by end-users (not only
> hackers).

I agree. Please place it their. The input stuff is pretty stable. We
should probably break it into pieces. 

Sourceforge project

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

Hi,

I've just had en eye to the sourceforge services the project is supposed
to use. One of these services is the forums. There are two of them: Help
and Open dicussions. Obviously, few of us ever consult them.
I think we should either keep an eye on those, leave messages to redirect
people to this mailing list, or close these forums.
Leaving this part abandonned may make people think the project is also
abandonned.

Another point is that perhaps we should release the input-part of the
project using the File List feature. Indeed, all the input stuff looks
pretty stable, and should be already fairly usable by end-users (not only
hackers).
I am personnaly involved in one of the input drivers (iforce), and I used
to distribute a patch containing the iforce driver from my own web
page. The patch actually contains all the input-related files. Should I
use the linuxconsole sourceforge site instead ?

-- 
Johann Deneux

Re: pm3fb (was: pm2fb driver)

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

> Here is a rough list of the problems I encountered today with the latest
> CVS version:
> - SMP: compiles, but hangs at boot time. No message can be seen, the
> screen just remains black.

Using VGA console? Must be a locking issue. I'm going to order another CPU
for my system today. 

> - serial code: failed to compile.
> gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
> serial_8250_pci.o serial_8250_pci.c
> serial_8250_pci.c:1079: sizeof applied to an incomplete type
> serial_8250_pci.c:1079: warning: initialization from incompatible pointer
> type
> make[2]: *** [serial_8250_pci.o] Error 1
> 
> However, I guess this problem may simply be a configuration-related
> problems. Why is this file compiled ? I guess it's only needed for
> additional serial  ports using a PCI card. If I am right, I do not think I
> need this. Where is the option to disable this file ? I do not see
> anything PCI-related in the serial driver seection  of the make menuconfig
> step.


I see you are trying out the new serial code. Don't enable the new serial
driver stuff. If you don't enable it the old stuff with reappear. That
stuff is experiemental. I will play with it this weekend.

> - matrox frame buffer: failed to compile.

Note ported over to ruby yet. That is a big job which will take several
days to do. 

> - key repeat: does not work well. Only 2 characters can be repeated. Is it
> a bug, or a default behaviour I can change ?

I believe this caused by the code in kd_mksound in vt_ioctl.c. Try
commenting that out and it should work. 

> - imPS2: the vertical wheel is inverted (or was it before ?)

Hm. Vojtech?

Re: [Linux-fbdev-devel] Re: Help from Gurus on modes and timing and frame buffers needed!

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

> Given all the cruft about video modes & flat panels lately, what about
> adding some generic fbdev mode management (extending modedb) this way:
> All driver that know how to retreive DDC/EDID informations or the old
> mac mode sense pins, provide this to the modedb module.
> 
> This module is responsible for using that info and command line infos
> to produce a sensible default display mode. It has a userland interface
> to make these infos easily available to candidate mode switchers (like
> MOL for example, but also a distribution XFree autoconfig tool).
> 
> It also has an event interface for drivers that can autodetect hotplug
> and unplug of the video connector. Actually, it could be in a more
> central place in fbdev arch and also do heads management.
> 
> In this case, drivers would register potential "heads" (connectors)
> indicating if they are independant or not (can only do mirroring), and
> if something is actually connected to them (most cards seem to be able
> to tell it).
> 
> We can have things like mirror-only heads that can have a different
> mode timing, our current interface doesn't seem really nice for it.
> This is classical on some laptops where the LCD is at 60hz, but you
> can mirror with a better refresh rate.
> 
> What do you think ?

That is what fbmon.c was made for!!!!!!! I agree we do need this kind of
functionality. Since this is a 2.5.X issue we can place it in the
linuxconsole project CVS. Their I'm working on the new fbdev api. I'm
willing to test it out. 

P.S

   Another issue is backlights and frontlights. I like to hammer something
out for that as well. I also already have hooks for power management as
well that feed up into the console layer. Also having fbdev doing power
management allows fbdev to exist without the console layer. 

Re: pm3fb (was: pm2fb driver)

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

On Tue, 6 Nov 2001, James Simmons wrote:

> 
> > Should we try to summarize all the problems encountered so far ?
> 
> Please do. 

Here is a rough list of the problems I encountered today with the latest
CVS version:
- SMP: compiles, but hangs at boot time. No message can be seen, the
screen just remains black.
- serial code: failed to compile.
gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
serial_8250_pci.o serial_8250_pci.c
serial_8250_pci.c:1079: sizeof applied to an incomplete type
serial_8250_pci.c:1079: warning: initialization from incompatible pointer
type
make[2]: *** [serial_8250_pci.o] Error 1

However, I guess this problem may simply be a configuration-related
problems. Why is this file compiled ? I guess it's only needed for
additional serial  ports using a PCI card. If I am right, I do not think I
need this. Where is the option to disable this file ? I do not see
anything PCI-related in the serial driver seection  of the make menuconfig
step.

- matrox frame buffer: failed to compile.

- key repeat: does not work well. Only 2 characters can be repeated. Is it
a bug, or a default behaviour I can change ?
- imPS2: the vertical wheel is inverted (or was it before ?)

I will try to give more details later. Time to sleep now.

-- 
Johann Deneux

[PATCH]

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

This patch allows you to set the IRQ and IO region for the i8042 chipset.
On certain platforms like mips these values vary alot. 

--- Config.in   Thu Nov  8 12:57:14 2001
+++ Config.in.new       Thu Nov  8 12:56:51 2001
@@ -10,6 +10,11 @@
    bool 'PS/2 port support' CONFIG_INPUT_PS2
    if [ "$CONFIG_INPUT_PS2" != "n" ]; then
       tristate '  i8042 aux+kbd controller' CONFIG_INPUT_I8042
+      if [ "$CONFIG_INPUT_I8042" != "n" ]; then
+         hex '    Register Base Address' CONFIG_I8042_REG_BASE 60
+        int '    PS/2 Keyboard IRQ' CONFIG_I8042_KBD_IRQ 1
+        int '    PS/2 AUX IRQ' CONFIG_I8042_AUX_IRQ 12
+      fi
       tristate '  ct82c710 aux controller' CONFIG_INPUT_CT82C710
       tristate '  Q40 kbd controller' CONFIG_INPUT_Q40KBD

Re: Spliting PCI from USB

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

On Wed, Nov 07, 2001 at 11:06:28AM -0800, James Simmons wrote:

> On several embedded devices they have OHCI chipsets but they don't have a
> PCI bus. I was wondering if it would be possible to rework the OHCI driver
> so that the PCI code would be in a seperate module. 

Yes, as far as I know it has already been done at least for ARM. Anyway,
the OHCI driver isn't too pci dependant. It's mostly a matter of
defining the proper pci_* macros (which should have been named dma_* or
something, it's not really pci-only stuff) and possibly #ifdef-ing out
some pci init stuff.

-- 
Vojtech Pavlik
SuSE Labs

Spliting PCI from USB

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

On several embedded devices they have OHCI chipsets but they don't have a
PCI bus. I was wondering if it would be possible to rework the OHCI driver
so that the PCI code would be in a seperate module. 

Re: Compile trouble (ARM merge ?)

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

> I've had to commit changes to 'drivers/Makefile' to
> get 2.4.13-ruby to 'make depend'. the 'drivers/hotplug'
> directory doesn't exist so putting it in 'subdir-y'
> would not allow compiling. Also, I had to comment out
> the config statement for l3. I didn't have problem with
> 'ssi', but as there was a typo ('subdif' instead of
> 'subdir') I removed it anyway (and fixed the typo).
> 
> Hope I didn't break to much stuff...

No you didn't. Thank you. I realized we just are going to have to give up
support for now on the ARM tree. The ac tree is way to different for the
drop in technique to work and I'm not going to put two trees into CVS. So
we will have to go with the tree's that are against Linus tree only which
luckly is most of them. Thanks for the fix to fbcon.c. 

Compile trouble (ARM merge ?)

[Romain D. <do...@ir...>]

Hello,

I've had to commit changes to 'drivers/Makefile' to
get 2.4.13-ruby to 'make depend'. the 'drivers/hotplug'
directory doesn't exist so putting it in 'subdir-y'
would not allow compiling. Also, I had to comment out
the config statement for l3. I didn't have problem with
'ssi', but as there was a typo ('subdif' instead of
'subdir') I removed it anyway (and fixed the typo).

Hope I didn't break to much stuff...

-- 
DOLBEAU Romain               |        Long live rock and
roll             
ENS Cachan / Ker Lann        |        Long live rock 'n'
roll             
Thesard IRISA / CAPS         |        Long live rock and
roll             
dol...@cl...    | -- Rainbow, 'Long Live Rock 'N' Roll'