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: James S. <jsi...@tr...> - 2001-05-28 20:17:26
|
Hi! This might be a improvement as several people had trouble with 2.4.4. Also the console display drivers initialization code has been cleaned up alot. It is really easy now to create a display driver. Also you can now have mda if configured by itself boot up right away like vgacon instead of later. I use this with fbcon to debug fbcon. Also we no longer need dummycon right away if every. Since the log buffer for printk is seperate I have it so printk messages are buffered until a console driver is loaded. Then it is flushed to the screen. This was a big step. The next steps for me is in order of most to least important are: 1) Write the font drawing code for dummy framebuffers. Important for vesafb and sa1100fb. 2) intergrate Andrew Morton's console/printk sync patches. 3) Fix VC resizing. You will be able to use stty to change your resolution :-) 4) Cleanup font handling. 5) Redo all the unicode code and have it work with Unicode 3.0 standard. It really sucks right now. 6) Rewrite GPM and remove selection code in the kernel. It doesn't belong their IMHO. 6) More improvements in the VT emulation code. |
|
From: James S. <jsi...@tr...> - 2001-05-18 18:35:39
|
> > 2) Framebuffer without keyboard/VT. Common case for emebedded devices. > > Same thing, you use /dev/fb directly without having to have a VT > > console. A VT console makes no since without a keyboard. > > For this case (and other odd uses) I did write a network input device > driver, so you can use a keyboard or joystick on one machine as if it is > on another. It needs a little more work to be useful, but I will do it if > anyone wants (basically you need ioctls to set capabilities on input > devices, matching the get ones, or you have to statically configure them). Actually I like to try to implement a input filesystem in the near future. Their was a long discussion about implementing devices as filesystems. One of the advantages of this is that you can nfs mount devices and run them remotely. |
|
From: James S. <jsi...@tr...> - 2001-05-17 18:36:51
|
> Scene 3: (PC keyboard + Serial Display: whithout VGA device) [snip].. > My question is the next: > > What driver can I use to manage Scene 3? > > I can run /sbin/login program over Serial Display > (using serial-console kernel support), but I can not > use the PC keyboard, because kernel thinks that we > are on Scene 1, so input must be from serial line and > I need input from PC keyboard. With the current tree you can't get around this. With the work we have been doing you can :-) This makes sense especially on handheld device which lack a keyboard but still has a visible display. So with the tree we have it is possible to 1) Use a regular keyboard without a VT. This is what you want to do. The device you want to use to do this /dev/input/eventX. One of them will be your keyboard. 2) Framebuffer without keyboard/VT. Common case for emebedded devices. Same thing, you use /dev/fb directly without having to have a VT console. A VT console makes no since without a keyboard. |
|
From: Javi R. <jav...@wa...> - 2001-05-17 12:01:45
|
I explain my question from any figures:
Simplified views of tty processing:
Scene 1: (Serial terminal)
User Program
|
| User space
---------------------------
| Kernel space
|
tty driver
|
--- ---
| |
| |
input output
handling handling
|
|
serial card driver
|
|
--------------------------
| Hardware
Serial Card
Scene 2: (PC console)
User Program
|
| User space
------------------------
| Kernel space
|
tty driver
|
-- --
| |
| |
input output
handling handling
|
|
console driver
|
|
-----------------------
| Hardware
---- ----
| |
PC keyboard PC Screen
Scene 3: (PC keyboard + Serial Display: whithout VGA device)
User Program
|
| User space
-------------------------
| Kernel space
|
tty driver
|
------
| |
| |
input output
handling handling
|
|
??? driver
|
|
-----------------------------
| Hardware
------ ------
| |
PC keyboard Serial Display (Text Display)
My question is the next:
What driver can I use to manage Scene 3?
I can run /sbin/login program over Serial Display
(using serial-console kernel support), but I can not
use the PC keyboard, because kernel thinks that we
are on Scene 1, so input must be from serial line and
I need input from PC keyboard.
Best regards. Javi Roman.
|
|
From: James S. <jsi...@tr...> - 2001-05-15 03:21:40
|
Hi Justin! I have begun porting the ruby tree to the arm platform (ipaq) and I seen you worked on the stowaway keybaord. Woudl you liek to port it over to the input api. I plan to work on the sa1100fb fbdev driver. |
|
From: James S. <jsi...@tr...> - 2001-05-09 17:43:08
|
I tested the latest stuff at my workstation at work. It worked fine but my personally machine at home did not. It appears their is a kernel bug that prevents my machine from booting :-( Will look into it. |
|
From: James S. <jsi...@tr...> - 2001-05-08 23:27:35
|
> Is the cvs tree synced with the non-patched version of kernel 2.4.4 ? Yes. > It seems this kernel won't run on smp machines (like mine) without Allan > Cox's patches (actually it crashed my smp box even with patch ac5, > but I have to try harder). Hum. I don't have a SMP machine. Anyone with a SMP machine to test stuff on? |
|
From: Johann D. <jo...@Do...> - 2001-05-08 20:39:57
|
Is the cvs tree synced with the non-patched version of kernel 2.4.4 ? It seems this kernel won't run on smp machines (like mine) without Allan Cox's patches (actually it crashed my smp box even with patch ac5, but I have to try harder). -- Johann Deneux CS student at DoCS (www.docs.uu.se/~johannd) and ESIL (www.esil.univ-mrs.fr/~jdeneux) |
|
From: James S. <jsi...@tr...> - 2001-05-08 05:50:33
|
Sorry about that. I fixed the tree. I missed syncing up fault.c correctly. I also reversed the removal of dummy console code. That was in my private tree and it accidently got sent to CVS. Everything should work fine. I tested it and it worked. It made me realize that I need to go over the code with a fine comb. After this many releases it was bound to happen. Next on the agenda: Finally merge Andrew Mortons patch with some improvements. I plan to do this by moving the vt lock into struct tty_driver. This way all locking can be handled by the tty layer and printk. This way lower level drivers don't have to worry about it. Next is the display driver initialization. It just is a mess. Evil code. I played with some ideas last weekend but it was a little more touchy then I thought. 3rd. VC resizing. I discovered it is possible to use stty to resize the current VC. WARNING this hangs the machine. I plan to have this fixed. 4th. Font support for fbcon to be added back in. To do this I need to do some cleaning up of font handling. Make it more generic. |
|
From: James S. <jsi...@tr...> - 2001-05-07 05:21:42
|
Hum. Interesting use of tar. > make xconfig > -> Errors in config.in. I fixed them as well as I could Fixed. It appears make xconfig is not as forgiving as make menuconfig or make config. Now it works. > make bzImage > -> Errors in one of the vt* files. The problem was a mutex. > Johann Deneux > CS student at DoCS (www.docs.uu.se/~johannd) and > ESIL (www.esil.univ-mrs.fr/~jdeneux) > Hum. I have had this error reported before but I couldn't reproduce it. Did you do a make dep first? Try a make dep then make bzImage. If this doesn't work then save you .config file somewhere and try a make mrproper. Move the config file back and try make dep;make bzImage. Let me know if this doesn't work. |
|
From: Johann D. <jo...@Do...> - 2001-05-06 08:20:48
|
Hi ! I tried to compile the code with a new 2.4.4 kernel, and it did not work. I am alone in this situation ? When I tried with the previous versions of the Linux console sources and a kernel 2.4.3 I got the same errors. Unfortunately, I don't have the errors at hand, but perhaps I did something wrong. Here is how I tried to compile the code: # Get the Linux console sources cvs login ... cvs co .../ruby # Save it tar cvzf ruby.tgz ruby/ # Extract linux sources cd ruby tar xvyf linux-2.4.4.tar.bz2 # Overwrite linux sources with Linux console sources cd .. tar xvzf ruby.tgz ruby/linux # Compile the stuff cd ruby/linux cp /usr/src/linux/.config . make xconfig -> Errors in config.in. I fixed them as well as I could make bzImage -> Errors in one of the vt* files. The problem was a mutex. Is there anything I did wrong ? If not, I will try again the compilation to have the exact errors. I used to have the same problems with the version for the linux kernl v. 2.4.3 -- Johann Deneux CS student at DoCS (www.docs.uu.se/~johannd) and ESIL (www.esil.univ-mrs.fr/~jdeneux) |
|
From: James S. <jsi...@tr...> - 2001-05-05 16:45:35
|
Hi! Just synced our tree with 2.4.4. I have some more improvements coming this way. Cleaner initalization code. Much finer higher level locking in the tty layer to deal with the printk DMA/irq issue. Really support for changing the console resolution. I discovered it can be done via stty. Note resizing the console is still experimental. I plan to stablize it this weekend. |
|
From: Vojtech P. <vo...@su...> - 2001-04-26 10:15:02
|
On Tue, Mar 27, 2001 at 10:38:29PM +0200, Ralf Ackermann wrote: > Many thanks, > > just getting sunkbd.c from the CVS and loading the compiled module worked > perfectly!! Glad to hear that. -- Vojtech Pavlik SuSE Labs |
|
From: Vojtech P. <vo...@su...> - 2001-04-26 10:14:58
|
On Tue, Mar 27, 2001 at 09:36:26PM +0200, Ralf Ackermann wrote: > Hello, > > i try using a serial sun5 keyboard on an x86 system. > I've used the adapter described at the "Linux Input Project" site - and > can see characters arriving on keypress / release when using e.g. minicom > on the serial port the keyboard is attached to. > > Unfortunately i fail to get the keyboard itself working > I'm using Linux 2.4.1. > I do an > insmod .../serial.o > insmod .../serio.o > insmod .../serport.o > > inputattach -skb /dev/ttyS0 & > > insmod .../input.o > insmod .../evdev.o > insmod .../keybdev.o > > but apart from an entry > Mar 27 23:01:16 dell kernel: serio0: Serial port tts/0 > in /var/log/messages i don't get any further reaction. > > Is there something special that i miss? sunkbd.o > Do i have to create any special > devices in /dev/... ? > How to debug the whole process? Is evtest usefull for that - or does it > primarly deal with joystick devices / mice? Evtest will work once the device is found. You're still missing the most important driver of the stack. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@li...> - 2001-04-19 17:03:07
|
>There already is a small lean X server in XFree86, missing only >acceleration and Linux input layer support, the one that was initially >written for the Ipaq (by Keith Packard afaik). It is abut 500k and >supports AA and most other extensions. It is in cvs now. Their is also Metro X which has the same thing. In fact that metro X server is used by the US military. See the metro X web site. The major problem is XFree86 uses a catherdal developement system. Which makes developement so slow. When do you think you will see his work become avaliable to everyone. Sure apps will be using gtk, qt and OpenGL but the problem is those inetrfaces use X underneath. GTk, Qt and OpenGL in time will develope so much faster that it will hinder their developement. >The reason that Berlin, ggi, kgi etc have failed is that they supported >none of these. DirectFB seems more hopeful, as they have started off with >gtk support, with working acceleration already. Since I'm working with X they will be supported rigth away. >Rasterman is rewriting enlightenment using GL isn't he? Yes. I seen a talk given by him the other day. In fact we had a long discussion about the X window design and XFree86 :-) |
|
From: James S. <jsi...@li...> - 2001-04-19 16:42:54
|
>I really think that this more of a step side-ways then forward, we need >to drop X. Why not set out to make a windowing system that can run ontop >of GFX or KGI?. X is old and should be shot. We need a new windowing >system that doesn't need a nasty hack that breaks the protocol to support >things like alpha blending and AA-fonts. Who cares about supporting >legacy X applications? The future market is only going to be concerned >with gnome and kde. gtk and qt could quickly be ported over to this new >system. X is old and can't be extended in a portable manner. I know I am >rambling but I have been waiting for someone to start up a new project >that might actually accomplish something usable sooner then berlin can. A >new protocol that is aimed at today's graphics market, but keeps the >future open is what is needed. Not another implementation of something >that should be left to die. X was great, buts its out lived its >usefullness. What do you think? X can be a power system. The problem is not with X but with XFree86. It just sucks on every level. I feel that it is time the open source community take over X and set it's course for us. |
|
From: James S. <jsi...@li...> - 2001-04-19 16:39:41
|
>you are forking the XFree86, is that the wisest course ? Do you have >enough manpower and coding time as compared to the Xfree86 team ? Not forking. Starting from scratch. We don't plan to stick with the MIT sample implementation for long. New build system, the whole nine yards. For several months several dozen developers have been exchange emails planning this. >Could you please explain a bit more about the reasons of this, and >explain why it is a better course than working with the Xfree code, and >adapting it to our needs. We feel the catherdal method of developement of XFree86 is going to hurt linux in the long run. We need something to evolve as fast or faster than linux. Also XFree86 design goal is to work everywhere. You have to pay a price for this. We are not so ambitious. |
|
From: John M. <tt...@te...> - 2001-04-19 01:56:46
|
I really think that this more of a step side-ways then forward, we need to drop X. Why not set out to make a windowing system that can run ontop of GFX or KGI?. X is old and should be shot. We need a new windowing system that doesn't need a nasty hack that breaks the protocol to support things like alpha blending and AA-fonts. Who cares about supporting legacy X applications? The future market is only going to be concerned with gnome and kde. gtk and qt could quickly be ported over to this new system. X is old and can't be extended in a portable manner. I know I am rambling but I have been waiting for someone to start up a new project that might actually accomplish something usable sooner then berlin can. A new protocol that is aimed at today's graphics market, but keeps the future open is what is needed. Not another implementation of something that should be left to die. X was great, buts its out lived its usefullness. What do you think? John On Wed, Apr 18, 2001 at 11:58:32AM -0700, James Simmons wrote: > > I wanted to post a message about the new direction for my work is > going to take place. As many know my goals have been to rework the console > layer by reworking the fbdev layer and using the input api. Yes it is not > the most exciting project so I have had a slow development cycle. > The reason I started this project was to lay the foundations for a new > infra structure for X windows and to fix the many problems with X and the > console system. It would allow the devleopement of smaller leaner X servers. > I still like to do this. > Last night I meet with rasterman and discussed several issues about X > and linux with him. In the discussion I realized that I need to work at a > faster pace to help further the developement of linux as a graphical UNIX > system. So the console project and the work beind it will be merging with > the GFX project. Another project which I started to provide a open source > X server besides XFree86. XFree86 was not designed with linux in mind and > it as many people have felt has failed the linux community. So I like to > announce the start of the linux GFX project which we will begain work on a > new X server written from scratch. I plan to continue the work of the > console project. I'm just combining it with gfX server. Especially since > the X server input core will be written completely around the input api. > I will shortly send a message to the kernel mailing list. Thank you. > > > > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxconsole-dev |
|
From: Sven L. <lu...@dp...> - 2001-04-18 23:34:45
|
On Wed, Apr 18, 2001 at 11:58:32AM -0700, James Simmons wrote: > > I wanted to post a message about the new direction for my work is > going to take place. As many know my goals have been to rework the console > layer by reworking the fbdev layer and using the input api. Yes it is not > the most exciting project so I have had a slow development cycle. > The reason I started this project was to lay the foundations for a new > infra structure for X windows and to fix the many problems with X and the > console system. It would allow the devleopement of smaller leaner X servers. > I still like to do this. > Last night I meet with rasterman and discussed several issues about X > and linux with him. In the discussion I realized that I need to work at a > faster pace to help further the developement of linux as a graphical UNIX > system. So the console project and the work beind it will be merging with > the GFX project. Another project which I started to provide a open source > X server besides XFree86. XFree86 was not designed with linux in mind and > it as many people have felt has failed the linux community. So I like to > announce the start of the linux GFX project which we will begain work on a > new X server written from scratch. I plan to continue the work of the > console project. I'm just combining it with gfX server. Especially since > the X server input core will be written completely around the input api. > I will shortly send a message to the kernel mailing list. Thank you. Huh, ... you are forking the XFree86, is that the wisest course ? Do you have enough manpower and coding time as compared to the Xfree86 team ? Could you please explain a bit more about the reasons of this, and explain why it is a better course than working with the Xfree code, and adapting it to our needs. Also interresting would be to know what part of the X code you will be reusing, and what part of it you won't be reusing. Notice also that this sort of moves will not make the Xfree people more happy with fbdev stuff in general :((( Friendly, Sven Luther |
|
From: James S. <jsi...@li...> - 2001-04-18 18:58:39
|
I wanted to post a message about the new direction for my work is
going to take place. As many know my goals have been to rework the console
layer by reworking the fbdev layer and using the input api. Yes it is not
the most exciting project so I have had a slow development cycle.
The reason I started this project was to lay the foundations for a new
infra structure for X windows and to fix the many problems with X and the
console system. It would allow the devleopement of smaller leaner X servers.
I still like to do this.
Last night I meet with rasterman and discussed several issues about X
and linux with him. In the discussion I realized that I need to work at a
faster pace to help further the developement of linux as a graphical UNIX
system. So the console project and the work beind it will be merging with
the GFX project. Another project which I started to provide a open source
X server besides XFree86. XFree86 was not designed with linux in mind and
it as many people have felt has failed the linux community. So I like to
announce the start of the linux GFX project which we will begain work on a
new X server written from scratch. I plan to continue the work of the
console project. I'm just combining it with gfX server. Especially since
the X server input core will be written completely around the input api.
I will shortly send a message to the kernel mailing list. Thank you.
|
|
From: James S. <jsi...@li...> - 2001-04-17 18:06:05
|
>i'm just about to make a module that enables a serial keyboard that >just sends make/break like codes in a PS/2 keyboard like coding: > >schematics: > PS/2 KB => straight-through PS/2 to serial converter => serial port > >http://www.iptel-now.de/HOWTO/RF_COMMUNICATION/rf_communication.html > http://www.iptel-now.de/HOWTO/PIC/pic.html > >This is for attaching PS/2 input devices to computers that only have >serial input (like the Compaq iPAQ PDAs). Thank you, thank you. I really need this for work. I'm also including David here since I heard he is working on this driver as well. I figure it would be better to work together on this. I included the handheld list as well since this impacts them. >I'm about to start with the code for sunkbd.c or the Newton/Stowaway >keyboard module. Before i do i would like to make sure that this >functionality doesn't exist already though, or there's a better way to >begin with. Not that I know about. COudl you post your work for people to test. P.S To the handhelds people. The linuxconsole project is a joint project between linux input api and fbdev developers to develope a new input/fbdev/console layer for 2.5.X. Some of the improvements is the movement of all input devices from touchscreens to joysticks and keybaords using the linux input api (/dev/input/eventX). The fbcon layer has been rewritten to seperate the console code from the fbdev drivers. This also allows fbdev drivers to exist independent of the console system. You could have a device that uses /dev/fb and the input interface but not have the bloat of have a VT console system included. Only a serial console is needed. To me this makes sense since several small hand helds devices don't have keyboards. This also allows for a universal api for input devices. |
|
From: James S. <jsi...@li...> - 2001-04-17 17:42:09
|
Hi! I traced the problem with the VESA framebuffer. It now runs fine as a indepedent frmaebuffer, no fbcon. I tried with fbcon but after mingetty starts running I reboot happens. I will track this down. First I have some big changes to handle what VT comes first. When testing fbcon I need mdacon as my inital VT so I can printk to it. Usually I had to hack up the code to do this. I hope in the next few days clean this issue up. |
|
From: James S. <jsi...@li...> - 2001-04-17 17:40:23
|
>It works fine for me. I use lots of devices all the time. I discovered the problem. A note to the SuSE developers on this list. SuSE 7.1 has the wrong minor numbers for /dev/input/eventX. They are the same as /dev/input/mouseX which was causing confussion. I had to use mknod to change the numbers. I really should use devfs. >I dont get these messages ever. Something may be wrong? Well only one USB hub port is working on my PC at work. The rest have seen better days :-( |
|
From: Ralf A. <ra...@KO...> - 2001-04-17 07:12:58
|
Hello, i'm just about to make a module that enables a serial keyboard that just sends make/break like codes in a PS/2 keyboard like coding: schematics: PS/2 KB => straight-through PS/2 to serial converter => serial port http://www.iptel-now.de/HOWTO/RF_COMMUNICATION/rf_communication.html http://www.iptel-now.de/HOWTO/PIC/pic.html This is for attaching PS/2 input devices to computers that only have serial input (like the Compaq iPAQ PDAs). I'm about to start with the code for sunkbd.c or the Newton/Stowaway keyboard module. Before i do i would like to make sure that this functionality doesn't exist already though, or there's a better way to begin with. Are there any suggestions, things that i should pay special attention too? best regards ralf -- Best regards, Ralf Ackermann |
|
From: James S. <jsi...@li...> - 2001-04-15 14:33:33
|
>i haven't looked much at the fbdev code lately, but ... > >in the design of ruby, did you look at the passage from cfb8/16/24/... to >fb in the XFree server ? Yes I did. It appears me and Keith Packard think along the same lines. The fillrect and copyarea are pretty much the same ideas exactly. I can tell you from my own benchmarks the fb layer will outperform by a large margin the cfb layer. The key is the word align. I know for intel platforms it makes a huge difference. On some platforms this is required. Thanks for the pointer. I'm looking at the font code. It will take some time to digest it. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
1998 messages has been excluded from this view by a project administrator.
