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...@in...> - 2002-10-28 23:31:48
|
Hi folks!!! After several lonng days of syncing up my new console code I'm nearly done. Unfortunely I have let the code code rot while it sat in Dave Jones tree. So I have updates it but now it has several bugs. Tonight I'm going to track them done but if people like to try this new code out and help me track the new bugs I would be very happy. You can grab the latest code via bitkeeper at bk://linuxconsole.bkbits.net/stable. I will make a diff in the next few hours. Thank you. 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...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Andreas S. <an...@sc...> - 2002-10-28 16:16:27
|
* Aivils Stoss (Aiv...@un...) [021024 09:51]: > > Andreas wrote: > >> >> Now understand. > >> >> > >> > > >> >COOL! that fixed it, actually. > > > >it fixed the oops. > > > >however, that bug had the side effect that the kbd_event() > >function returns immediatly without calling kbd_keycode() any > >more, because > >if (!vt->fg_console->vc_tty) return; > > > >we did set the vc->vc_tty=NULL in vt_close, after all. > > > >So it would be better to actually find a free tty (from the > >vty_driver->table, which holds all the vt`s ttys. Are they > >intendet for this purpose?). > > > >so how does one recognize a free tty? > > I mistake. keyboard.c is vc->vc_tty == NULL safe. that actually fixes that oops, but it does create other funnies, which make me think that it would be necessary to differentiat a little more. for me this change made the first vc (vc0) on VT0 dissapear. as one result the shifting through the VCs with ALT-Left and ALT-Right does now end at vt6 and vt1. vt7 and vt0 became invalid. this is checked for in vt_callback, where the actual switching happens. Again, i think this needs to be initialized properly. I have stared at the VC, TTY and VT code for some time now but do not understand how this would be initialized correctly in vt_close. Do we need some check if we are closing a tty which is associated to the VCs? I have the code for tty paranoia checking compiled in and if it works correctly this should be caught in relese_dev in tty_io.c. on other switching bug is in fn_dec_console fn_inc_console in keyboard.c. this surfaces when we try the console switching on a dumb VT. strangly i get an oops only if decrementing (alt-left) the vc, eventhough it should trigger the same error in incrementing the console. again, this is an initialisation issue, because find_vc return a nullpointer if the tty/vc is not initialised correctly. This nullpointer would get dereferenced in set_console() and that causes the oops. James, could you write something up about the initialisation strategy and stuff? attached find some obvious fixes for vt.c. non of these address the issues mentioned above. |
|
From: Aivils S. <Aiv...@un...> - 2002-10-28 08:31:28
|
Adam Hunt wrote >I'm just trying to clarify what the issuses are surrounding having one >computer with multiple monitors, keyboards and mice serve multiple users localy. > >Video -- This seems to have been solved by the new wonderful framebuffer >layer. Two or more VT's with their associated framebuffers and xservers. Needs lot of work. Current CVS support one VT per all fb layer. >Mice -- We can have more then one mouse control a single pointer but how do >we get mouse 1 on VT1, mouse 2 on VT2, etc... I don't know. X do not ask for VT but /dev/ttyX /dev/input/mouseX. You can analyze gpm. >Keyboards -- This seems to be the major issue. IIRC the code for handling >the keyboard is deeply rooted in XF86's codebase (correct me if I am wrong). >It was never intended that a single box would have more then one keyboard >connected. [Is anyone working on this? Are there any theoretical >soutions/hacks/clean-fixes?] Not so deeply in XF86's. You can run multiple independ X without kernel patch. Check out http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/ >Sound -- Not really a primary goal but most likelly this is doable. Under Linux we have not common sound solution. Any application use different sound layer. I patch /usr/bin/startkde. Now this script push into ~/.kde/share/config/kcmartsrc with right content. User can run apps with aRTs support with his sound card. This will not work for other desktop manager and games. I have two sound cards in the box. es1371,es5880 - system crash with joystik support. idsoftware production allow: $ quake3 +set snddevice /dev/dsp2 >Floppy/CDROM Access -- Also not a primary goal but with USB hardware and >symlinks this can most likelly be done. IMHO defined in the /etc/fstab under redhat /etc/security/console.perms Aivils Stoss |
|
From: Adam H. <ada...@gm...> - 2002-10-26 00:12:49
|
I'm just trying to clarify what the issuses are surrounding having one computer with multiple monitors, keyboards and mice serve multiple users localy. Video -- This seems to have been solved by the new wonderful framebuffer layer. Two or more VT's with their associated framebuffers and xservers. Mice -- We can have more then one mouse control a single pointer but how do we get mouse 1 on VT1, mouse 2 on VT2, etc... Keyboards -- This seems to be the major issue. IIRC the code for handling the keyboard is deeply rooted in XF86's codebase (correct me if I am wrong). It was never intended that a single box would have more then one keyboard connected. [Is anyone working on this? Are there any theoretical soutions/hacks/clean-fixes?] Sound -- Not really a primary goal but most likelly this is doable. Floppy/CDROM Access -- Also not a primary goal but with USB hardware and symlinks this can most likelly be done. Thank you for all your help. Any corrections, thoughts, flames, rants, etc. would be gladly accepted. --adam (obsessed multiheaded crackhead) I *KNOW* this is possible it just may take some (tons of) work. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! |
|
From: Andreas S. <an...@sc...> - 2002-10-25 23:20:49
|
* Adam Hunt (ada...@gm...) [021025 23:51]: > I'm working on getting two or more indenpendent X sessions running on a > single box. I'm a bit confused how I configure the first [USB] keyboard and > mouse set to run on a specified VT and then configure the second set to run on > another. on http://startx.times.lv/ , in the FAQs, that is explained... that that is not possible yet. Not straightforward, at least. in the XF86Config you can determin what mouse device goes to which Xserver. you can also configure which Xserver goes with which VT. What you can not configure is which keyboard goes with which VT. During initialisation the first keyboard found goes to the first VT, the second to the second one, usw. And if you have any special keyboards, like one with extra mulitmedia keys (a microsoft keyboard i have here), this one keyboard will register as two keyboards and you need a dummy VT just to satisfy that multimedia-keys-subkeyboard. |
|
From: Adam H. <ada...@gm...> - 2002-10-25 21:50:40
|
I'm working on getting two or more indenpendent X sessions running on a single box. I'm a bit confused how I configure the first [USB] keyboard and mouse set to run on a specified VT and then configure the second set to run on another. I'm interested in a v2.5 kernel solution but v2.4 info is welcom as well. --adam -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! |
|
From: Andreas S. <an...@sc...> - 2002-10-22 07:52:02
|
* Adam Hunt (ada...@gm...) [021022 03:14]: > I am interested running multiple independent X servers on a multiheaded box > to server multiple concurrent X users. I have read some info at > startx.times.lv but it seems to be centered arround 2.4. I am looking to use 2.6/3.0 in > a future production (public library) environment. then it might well be rather effordless. James Simmons recently wrote that the multihead stuff is likely to go into 2.5 before the feature freeze. That is what you would need (among others). apart form that there are some useability problems to be solved. |
|
From: Adam H. <ada...@gm...> - 2002-10-22 01:13:17
|
I am interested running multiple independent X servers on a multiheaded box to server multiple concurrent X users. I have read some info at startx.times.lv but it seems to be centered arround 2.4. I am looking to use 2.6/3.0 in a future production (public library) environment. thanks. --adam -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! |
|
From: James S. <jsi...@in...> - 2002-10-21 17:49:08
|
> Is the new console layer doing to be merged into 2.5 before the freeze? > Is it even stable yet? Hi folks!! First of all I like to say thanks for all the people working on this project with us. I'm sorry I haven't been around more, especially the last two months. As some of you know I ended up in the hospital for a few weeks and was on cruches. Now I'm find but still recovering. Then I got married!!!! So I was gone on my honeymoon and I'm still adjusting to married lfe. Also I'm still unemployed :-( Now for what has been accomplished. The console project is a huge project. Far larging than most projects. We are reworking the console layer, input layer and graphics layer. Once I thought bad because the core console layer didn't go in, but in reality it did. The input layer is now the back bone of the console layer. The framebuffer changes are almost complete. I have one last set of changes to send linus. What needs to be done. Ruby needs to be updated. I started this update in the linuxconsole BK tree and will soon dump the code into CVS. Give me a few days and we can go into testing mode. A few of the feature of ruby will not go in since we don't have time to test them tho. Mainly the new console locking code. That will be for round two. The multihead stuff will go in. |
|
From: Aivils S. <Aiv...@un...> - 2002-10-21 13:21:01
|
>ok, some more research, but i still do not understand what really
>happens.
>
>the tty_struct which later is found from kdb_keycode and causes
>the oops in tty_insert_flip_char() is correctly kfree()d much
>earlier, when the tty is shut down at some point. (they seem to
>be opened and released all the time for different purposes.)
>
>But in the vc->vc_tty pointer keeps pointing to the old, freed
>tty_struct.
>where should that pointer be reset, if a tty is released?
>
>Shouldnt this happen in tty_io.c in release_dev()? this is not
>the case in ruby or in Aivils backport to 2.4.
Now understand.
--- drivers/char/vt.c.orig Mon Sep 23 21:19:26 2002
+++ drivers/char/vt.c Mon Oct 21 18:46:36 2002
@@ -1277,11 +1277,14 @@ static int vt_open(struct tty_struct *tt
static void vt_close(struct tty_struct *tty, struct file *filp)
{
+ struct vc_data *vc;
if (!tty)
return;
if (tty->count != 1)
return;
vcs_make_devfs(minor(tty->device), 1);
+ vc = (struct vc_data *) tty->driver_data;
+ vc->vc_tty = NULL;
tty->driver_data = 0;
}
James Simons
Current ruby CVS call vt_map_input() vt.c any time when keyboard pluged
into box.
If user plug USB keyboard multiple times in vt_map_input() vty_driver
allocated
again and again, called from kbd_connect() keyboard.c.
Your sugestion?
1) Free vty_driver in the kbd_disconnect()
or
2) ignore vt_map_input() second call from kbd_connect() if vty_driver
already
allocated for this VT.
Me like 2) because VT never released.
Aivils Stoss
|
|
From: Andreas S. <an...@sc...> - 2002-10-20 22:14:53
|
ok, some more research, but i still do not understand what really happens. the tty_struct which later is found from kdb_keycode and causes the oops in tty_insert_flip_char() is correctly kfree()d much earlier, when the tty is shut down at some point. (they seem to be opened and released all the time for different purposes.) But in the vc->vc_tty pointer keeps pointing to the old, freed tty_struct. where should that pointer be reset, if a tty is released? Shouldnt this happen in tty_io.c in release_dev()? this is not the case in ruby or in Aivils backport to 2.4. |
|
From: Andreas S. <an...@sc...> - 2002-10-19 17:11:03
|
* Andreas Schuldei (an...@sc...) [021011 12:26]: > i am observing a memory corruption in the tty_struct. (at least) > the flip structure is overwritten. I know that this can not only > be due to the backport to 2.4 (i use the ruby backport) and to > Aivils added memset()s after kalloc()s, because there is a > comment in that flip stucture saying: > >·······unsigned char>··slop[4]; /* N.B. bug overwrites buffer by 1 */ alan cox (i met him at a linux fair this week) said this was from before 2.4 and is fixed. so we could clean this up. He also was very interested in the mulit-user multi-console thing. But then he is also very polite. (c: > So has someone experienced something similar and found the > reason? and now i also found the inital cause (not yet the solution): this happens during boottime when loadkeys is running. kernel memory is free()d but the pointer to the memory is still used as before. My guess is that only people who actually load a keymap (speak: non americans) at boottime are bitten by this. if loadkeys is not run, all is fine. |
|
From: James S. <jsi...@in...> - 2002-10-17 18:49:15
|
> > Give it a try. For people who want a diff it is avaiable at > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > ... which is not representative of the changes. > > Can you _please_ take much more care over patches and such like and take > the time to get them correct _please_. > > I really don't like patches that float around that unintentionally delete > other peoples drivers for no reason. Ugh!! I forgot to do a bk -r co -q on the fbdev BK respoitory before I made the diff. I will create a new diff and post it. I apologize for that. |
|
From: Russell K. <rm...@ar...> - 2002-10-17 17:28:11
|
On Thu, Oct 17, 2002 at 09:38:37AM -0700, James Simmons wrote: > I like to annouce that I just finished the final fbdev changes. They are > in the BK repository bk://fbdev.bkbits.net/fbdev-2.5. The changes are > > 1) Removal of all console related code in the lower level drivers. Smaller > easier to program drivers. > > 2) Now you can use the framebuffer driver WITHOUT framebuffer console. > Last night I built a kernel with MDA console and used the VESA > framebuffer by itself. Now you can easily debug new framebuffer > drivers. The real bonus is for embedded systems you have much smaller > kernels. > > 3) I moved the agp and drm code into drivers/video. I did NOT place any > drm code with framebuffer code at people's request. I simiple moved the > directory from one spot to another. The main reason I did this was > because some framebuffer drivers will need to use the agp code initialized > before the framebuffer layer. The DRM code was moved because it makes > sense to move it there. > > 4) I cleaned up the config.in for all the video stuff across all > platforms. > > You can grab the lastest BK tree at > > bk://fbdev.bkbits.net/fbdev-2.5 > > Give it a try. For people who want a diff it is avaiable at > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz ... which is not representative of the changes. Can you _please_ take much more care over patches and such like and take the time to get them correct _please_. I really don't like patches that float around that unintentionally delete other peoples drivers for no reason. -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
|
From: James S. <jsi...@in...> - 2002-10-17 16:45:14
|
Hi! I like to annouce that I just finished the final fbdev changes. They are in the BK repository bk://fbdev.bkbits.net/fbdev-2.5. The changes are 1) Removal of all console related code in the lower level drivers. Smaller easier to program drivers. 2) Now you can use the framebuffer driver WITHOUT framebuffer console. Last night I built a kernel with MDA console and used the VESA framebuffer by itself. Now you can easily debug new framebuffer drivers. The real bonus is for embedded systems you have much smaller kernels. 3) I moved the agp and drm code into drivers/video. I did NOT place any drm code with framebuffer code at people's request. I simiple moved the directory from one spot to another. The main reason I did this was because some framebuffer drivers will need to use the agp code initialized before the framebuffer layer. The DRM code was moved because it makes sense to move it there. 4) I cleaned up the config.in for all the video stuff across all platforms. You can grab the lastest BK tree at bk://fbdev.bkbits.net/fbdev-2.5 Give it a try. For people who want a diff it is avaiable at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note it is huge and against 2.5.43. The framebuffer console system is kind of flaky still since the api has changed alot. So alot of work will be done on fbcon.c from now on besides porting the drivers over. Have fun. CREDITS | 13 Documentation/DocBook/kernel-api.tmpl | 4 MAINTAINERS | 7 arch/alpha/config.in | 17 arch/arm/config.in | 10 arch/i386/config.in | 12 arch/i386/vmlinux.lds.s | 105 arch/ia64/config.in | 11 arch/m68k/config.in | 7 arch/mips/config.in | 11 arch/mips64/config.in | 15 arch/parisc/config.in | 19 arch/ppc/config.in | 7 arch/ppc64/config.in | 7 arch/sh/config.in | 13 arch/sparc/config.in | 7 arch/sparc64/config.in | 4 arch/x86_64/config.in | 12 drivers/Makefile | 3 drivers/char/Config.in | 202 drivers/char/Makefile | 2 drivers/char/agp/Config.help | 88 drivers/char/agp/Config.in | 22 drivers/char/agp/Makefile | 24 drivers/char/agp/agp.c | 1690 ---- drivers/char/agp/agp.h | 377 - drivers/char/agp/ali-agp.c | 265 drivers/char/agp/amd-agp.c | 408 - drivers/char/agp/frontend.c | 1086 -- drivers/char/agp/hp-agp.c | 394 - drivers/char/agp/i460-agp.c | 595 - drivers/char/agp/i810-agp.c | 594 - drivers/char/agp/i8x0-agp.c | 731 - drivers/char/agp/k8-agp.c | 476 - drivers/char/agp/sis-agp.c | 142 drivers/char/agp/sworks-agp.c | 626 - drivers/char/agp/via-agp.c | 151 drivers/char/drm/Config.help | 39 drivers/char/drm/Config.in | 17 drivers/char/drm/Makefile | 23 drivers/char/drm/README.drm | 46 drivers/char/drm/ati_pcigart.h | 203 drivers/char/drm/drm.h | 461 - drivers/char/drm/drmP.h | 908 -- drivers/char/drm/drm_agpsupport.h | 370 drivers/char/drm/drm_auth.h | 163 drivers/char/drm/drm_bufs.h | 1137 --- drivers/char/drm/drm_context.h | 781 -- drivers/char/drm/drm_dma.h | 657 - drivers/char/drm/drm_drawable.h | 51 drivers/char/drm/drm_drv.h | 1085 -- drivers/char/drm/drm_fops.h | 209 drivers/char/drm/drm_init.h | 116 drivers/char/drm/drm_ioctl.h | 249 drivers/char/drm/drm_lists.h | 230 drivers/char/drm/drm_lock.h | 251 drivers/char/drm/drm_memory.h | 467 - drivers/char/drm/drm_os_linux.h | 90 drivers/char/drm/drm_proc.h | 633 - drivers/char/drm/drm_scatter.h | 225 drivers/char/drm/drm_stub.h | 151 drivers/char/drm/drm_vm.h | 503 - drivers/char/drm/ffb.h | 15 drivers/char/drm/ffb_context.c | 539 - drivers/char/drm/ffb_drv.c | 401 - drivers/char/drm/ffb_drv.h | 276 drivers/char/drm/gamma.h | 148 drivers/char/drm/gamma_dma.c | 833 -- drivers/char/drm/gamma_drm.h | 89 drivers/char/drm/gamma_drv.c | 55 drivers/char/drm/gamma_drv.h | 120 drivers/char/drm/i810.h | 117 drivers/char/drm/i810_dma.c | 1253 --- drivers/char/drm/i810_drm.h | 248 drivers/char/drm/i810_drv.c | 56 drivers/char/drm/i810_drv.h | 207 drivers/char/drm/i830.h | 103 drivers/char/drm/i830_dma.c | 1291 --- drivers/char/drm/i830_drm.h | 251 drivers/char/drm/i830_drv.c | 58 drivers/char/drm/i830_drv.h | 216 drivers/char/drm/mga.h | 94 drivers/char/drm/mga_dma.c | 795 -- drivers/char/drm/mga_drm.h | 325 drivers/char/drm/mga_drv.c | 52 drivers/char/drm/mga_drv.h | 631 - drivers/char/drm/mga_state.c | 1077 -- drivers/char/drm/mga_ucode.h |11645 ------------------------------- drivers/char/drm/mga_warp.c | 212 drivers/char/drm/r128.h | 110 drivers/char/drm/r128_cce.c | 1010 -- drivers/char/drm/r128_drm.h | 308 drivers/char/drm/r128_drv.c | 55 drivers/char/drm/r128_drv.h | 504 - drivers/char/drm/r128_state.c | 1566 ---- drivers/char/drm/radeon.h | 154 drivers/char/drm/radeon_cp.c | 1648 ---- drivers/char/drm/radeon_drm.h | 563 - drivers/char/drm/radeon_drv.c | 53 drivers/char/drm/radeon_drv.h | 867 -- drivers/char/drm/radeon_irq.c | 256 drivers/char/drm/radeon_mem.c | 334 drivers/char/drm/radeon_state.c | 2190 ----- drivers/char/drm/sis.h | 81 drivers/char/drm/sis_drm.h | 46 drivers/char/drm/sis_drv.c | 49 drivers/char/drm/sis_drv.h | 45 drivers/char/drm/sis_ds.c | 406 - drivers/char/drm/sis_ds.h | 163 drivers/char/drm/sis_mm.c | 307 drivers/char/drm/tdfx.h | 42 drivers/char/drm/tdfx_drv.c | 92 drivers/video/Config.help | 149 drivers/video/Config.in | 457 - drivers/video/Makefile | 44 drivers/video/agp/Config.help | 88 drivers/video/agp/Config.in | 22 drivers/video/agp/Makefile | 24 drivers/video/agp/agp.c | 1690 ++++ drivers/video/agp/agp.h | 377 + drivers/video/agp/ali-agp.c | 265 drivers/video/agp/amd-agp.c | 408 + drivers/video/agp/frontend.c | 1086 ++ drivers/video/agp/hp-agp.c | 394 + drivers/video/agp/i460-agp.c | 595 + drivers/video/agp/i810-agp.c | 594 + drivers/video/agp/i8x0-agp.c | 731 + drivers/video/agp/k8-agp.c | 476 + drivers/video/agp/sis-agp.c | 142 drivers/video/agp/sworks-agp.c | 626 + drivers/video/agp/via-agp.c | 151 drivers/video/anakinfb.c | 117 drivers/video/aty/atyfb_base.c | 2711 ------- drivers/video/aty/mach64_ct.c | 2 drivers/video/aty/mach64_cursor.c | 2 drivers/video/aty/mach64_gx.c | 2 drivers/video/aty128fb.c | 3167 +++----- drivers/video/cfbcopyarea.c | 230 drivers/video/cfbfillrect.c | 107 drivers/video/cfbimgblt.c | 335 drivers/video/clps711xfb.c | 452 - drivers/video/console/Config.help | 149 drivers/video/console/dummycon.c | 74 drivers/video/console/fbcon-accel.c | 189 drivers/video/console/fbcon-accel.h | 34 drivers/video/console/fbcon-afb.c | 448 + drivers/video/console/fbcon-hga.c | 253 drivers/video/console/fbcon-ilbm.c | 296 drivers/video/console/fbcon-iplan2p2.c | 476 + drivers/video/console/fbcon-iplan2p4.c | 497 + drivers/video/console/fbcon-iplan2p8.c | 534 + drivers/video/console/fbcon-sti.c | 337 drivers/video/console/fbcon-vga-planes.c | 281 drivers/video/console/font_6x11.c | 3351 ++++++++ drivers/video/console/font_8x16.c | 4631 ++++++++++++ drivers/video/console/font_8x8.c | 2583 ++++++ drivers/video/console/font_acorn_8x8.c | 277 drivers/video/console/font_mini_4x6.c | 2158 +++++ drivers/video/console/font_pearl_8x8.c | 2587 ++++++ drivers/video/console/font_sun12x22.c | 6220 ++++++++++++++++ drivers/video/console/font_sun8x16.c | 275 drivers/video/console/fonts.c | 135 drivers/video/console/mdacon.c | 632 + drivers/video/console/newport_con.c | 746 + drivers/video/console/prom.uni | 11 drivers/video/console/promcon.c | 606 + drivers/video/console/sti-bmode.h | 287 drivers/video/console/sticon-bmode.c | 895 ++ drivers/video/console/sticon.c | 215 drivers/video/console/vgacon.c | 1062 ++ drivers/video/dnfb.c | 275 drivers/video/drm/Config.help | 39 drivers/video/drm/Config.in | 17 drivers/video/drm/Makefile | 23 drivers/video/drm/README.drm | 46 drivers/video/drm/ati_pcigart.h | 203 drivers/video/drm/drm.h | 461 + drivers/video/drm/drmP.h | 908 ++ drivers/video/drm/drm_agpsupport.h | 370 drivers/video/drm/drm_auth.h | 163 drivers/video/drm/drm_bufs.h | 1137 +++ drivers/video/drm/drm_context.h | 781 ++ drivers/video/drm/drm_dma.h | 657 + drivers/video/drm/drm_drawable.h | 51 drivers/video/drm/drm_drv.h | 1085 ++ drivers/video/drm/drm_fops.h | 209 drivers/video/drm/drm_init.h | 116 drivers/video/drm/drm_ioctl.h | 249 drivers/video/drm/drm_lists.h | 230 drivers/video/drm/drm_lock.h | 251 drivers/video/drm/drm_memory.h | 467 + drivers/video/drm/drm_os_linux.h | 90 drivers/video/drm/drm_proc.h | 633 + drivers/video/drm/drm_scatter.h | 225 drivers/video/drm/drm_stub.h | 151 drivers/video/drm/drm_vm.h | 503 + drivers/video/drm/ffb.h | 15 drivers/video/drm/ffb_context.c | 539 + drivers/video/drm/ffb_drv.c | 401 + drivers/video/drm/ffb_drv.h | 276 drivers/video/drm/gamma.h | 148 drivers/video/drm/gamma_dma.c | 833 ++ drivers/video/drm/gamma_drm.h | 89 drivers/video/drm/gamma_drv.c | 55 drivers/video/drm/gamma_drv.h | 120 drivers/video/drm/i810.h | 117 drivers/video/drm/i810_dma.c | 1253 +++ drivers/video/drm/i810_drm.h | 248 drivers/video/drm/i810_drv.c | 56 drivers/video/drm/i810_drv.h | 207 drivers/video/drm/i830.h | 103 drivers/video/drm/i830_dma.c | 1291 +++ drivers/video/drm/i830_drm.h | 251 drivers/video/drm/i830_drv.c | 58 drivers/video/drm/i830_drv.h | 216 drivers/video/drm/mga.h | 94 drivers/video/drm/mga_dma.c | 795 ++ drivers/video/drm/mga_drm.h | 325 drivers/video/drm/mga_drv.c | 52 drivers/video/drm/mga_drv.h | 631 + drivers/video/drm/mga_state.c | 1077 ++ drivers/video/drm/mga_ucode.h |11645 +++++++++++++++++++++++++++++++ drivers/video/drm/mga_warp.c | 212 drivers/video/drm/r128.h | 110 drivers/video/drm/r128_cce.c | 1010 ++ drivers/video/drm/r128_drm.h | 308 drivers/video/drm/r128_drv.c | 55 drivers/video/drm/r128_drv.h | 504 + drivers/video/drm/r128_state.c | 1566 ++++ drivers/video/drm/radeon.h | 154 drivers/video/drm/radeon_cp.c | 1648 ++++ drivers/video/drm/radeon_drm.h | 563 + drivers/video/drm/radeon_drv.c | 53 drivers/video/drm/radeon_drv.h | 867 ++ drivers/video/drm/radeon_irq.c | 256 drivers/video/drm/radeon_mem.c | 334 drivers/video/drm/radeon_state.c | 2190 +++++ drivers/video/drm/sis.h | 81 drivers/video/drm/sis_drm.h | 46 drivers/video/drm/sis_drv.c | 49 drivers/video/drm/sis_drv.h | 45 drivers/video/drm/sis_ds.c | 406 + drivers/video/drm/sis_ds.h | 163 drivers/video/drm/sis_mm.c | 307 drivers/video/drm/tdfx.h | 42 drivers/video/drm/tdfx_drv.c | 92 drivers/video/dummycon.c | 74 drivers/video/fbcmap.c | 57 drivers/video/fbcon-accel.c | 188 drivers/video/fbcon-accel.h | 34 drivers/video/fbcon-afb.c | 448 - drivers/video/fbcon-cfb16.c | 319 drivers/video/fbcon-cfb2.c | 225 drivers/video/fbcon-cfb24.c | 333 drivers/video/fbcon-cfb32.c | 305 drivers/video/fbcon-cfb4.c | 229 drivers/video/fbcon-cfb8.c | 294 drivers/video/fbcon-hga.c | 253 drivers/video/fbcon-ilbm.c | 296 drivers/video/fbcon-iplan2p2.c | 476 - drivers/video/fbcon-iplan2p4.c | 497 - drivers/video/fbcon-iplan2p8.c | 534 - drivers/video/fbcon-mfb.c | 217 drivers/video/fbcon-sti.c | 337 drivers/video/fbcon-vga-planes.c | 387 - drivers/video/fbcon.c | 2509 ------ drivers/video/fbgen.c | 217 drivers/video/fbmem.c | 961 -- drivers/video/fm2fb.c | 14 drivers/video/font_6x11.c | 3351 -------- drivers/video/font_8x16.c | 4631 ------------ drivers/video/font_8x8.c | 2583 ------ drivers/video/font_acorn_8x8.c | 277 drivers/video/font_mini_4x6.c | 2158 ----- drivers/video/font_pearl_8x8.c | 2587 ------ drivers/video/font_sun12x22.c | 6220 ---------------- drivers/video/font_sun8x16.c | 275 drivers/video/fonts.c | 135 drivers/video/g364fb.c | 268 drivers/video/hitfb.c | 14 drivers/video/hpfb.c | 15 drivers/video/macfb.c | 978 -- drivers/video/macmodes.c | 387 - drivers/video/maxinefb.c | 192 drivers/video/mdacon.c | 632 - drivers/video/modedb.c | 7 drivers/video/neofb.c | 25 drivers/video/newport_con.c | 746 - drivers/video/offb.c | 559 - drivers/video/pmag-ba-fb.c | 14 drivers/video/pmagb-b-fb.c | 14 drivers/video/prom.uni | 11 drivers/video/promcon.c | 606 - drivers/video/q40fb.c | 13 drivers/video/sa1100fb.c | 2 drivers/video/sgivwfb.c | 21 drivers/video/sis/Makefile | 2 drivers/video/sis/sis_accel.c | 495 + drivers/video/skeletonfb.c | 20 drivers/video/sti-bmode.h | 287 drivers/video/sticon-bmode.c | 895 -- drivers/video/sticon.c | 215 drivers/video/tdfxfb.c | 376 - drivers/video/tx3912fb.c | 13 drivers/video/vesafb.c | 386 - drivers/video/vfb.c | 17 drivers/video/vga16fb.c | 943 -- drivers/video/vgacon.c | 1055 -- include/linux/fb.h | 546 - include/linux/sisfb.h | 58 include/video/fbcon-cfb16.h | 34 include/video/fbcon-cfb2.h | 32 include/video/fbcon-cfb24.h | 34 include/video/fbcon-cfb32.h | 34 include/video/fbcon-cfb4.h | 32 include/video/fbcon-cfb8.h | 34 include/video/fbcon-mac.h | 32 include/video/fbcon-vga-planes.h | 1 include/video/fbcon.h | 795 -- 321 files changed, 82006 insertions(+), 96749 deletions(-) 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...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Louis G. <lou...@be...> - 2002-10-16 17:43:27
|
Is the new console layer doing to be merged into 2.5 before the freeze? Is it even stable yet? --Lou |
|
From: Aivils S. <Aiv...@un...> - 2002-10-14 07:24:06
|
>> > This patch fixes some of the missed handle_sysrq functions not updated. >> > please apply. >> >> Are you going to have early console support (ie printk from before >> what is now console_init) done before the freeze, or should I just >> submit our version? > >Depends on how fast Linus takes my patches. In the end vty_init will >initialize display drivers that need a other resource that are avaliable >latter (i.e pci handling, irqs) and the other drivers will be called by >vt_console_init. vt_console_init can be called much earlier than now. In >fact I will soon remove the need to call bootmem. I plan to removal all >the console related stuff from the arch directories!!! It can be done with >some work. I done it for the ix86 platform. The need for a dummy console >will also go away. If You remove dummy console, You create ruby CVS bug: "Unable to open initial console" The whys: 1) keyboard drivers not compiled into kernel 2) null keyboards pluged in the box. 3) null consoles compiled into kernel. Aivils Stoss |
|
From: Andi K. <ak...@mu...> - 2002-10-14 01:18:44
|
Andrew Morton <ak...@di...> writes:
> I think what we need James is just the low-level hook in printk.c which
> the various platforms and boards can plug into. The one in Martin's
> patch (module some cleanups, docco, conversion to C, etc) looks
> suitable to me. The actual early console drivers don't appear to have
> much relationship at all to the console layer really. They're just
> minimal-code busy-wait port banging.
The hook already exists and it is called register_console. Has been there
for years. early_printk on x86-64 uses that. Originally I used the hackish
printk hook way, but Linus put me on the right track.
Your arch code just does a register_console very early which does the low level
output.
Actually you need one new hook for cosmetic reason: when the real console
starts you want to disable the early console, otherwise you get duplicated
output when they go to the same output device. This can be done with a
straight forward function call in console_init.
BTW the x86-64 early console should just work fine on i386 too, with minor
changes.
All you need to do is:
- cp arch/x86_64/kernel/early_printk.c arch/i386/kernel/early_printk.c
- edit arch/i386/kernel/early_printk.c and replace VGABASE with
__PAGE_OFFSET+0xb8000
- add it to arch/i386/kernel/Makefile
- (optional - if you don't do it will be only initialised after setup_arch when
__setup arguments are parsed)
add something like
if (c == ' ' && !memcmp(from,"earlyprintk=",12)) {
extern int setup_early_printk(char *opt)
setup_early_printk(from+12);
}
to the comand line parsing in arch/i386/kernel/setup.c
- Enable CONFIG_EARLY_PRINTK so that console_init disables it.
- Boot with earlyprintk=vga (for vga output)
or earlyprintk=serial,ttySx,baud for serial output.
Add ,keep when you want to keep it even after console_init
-Andi
|
|
From: Anton B. <an...@sa...> - 2002-10-13 22:34:00
|
> Ugh!!! The reason I reworked the console system is because over the years > hack after hack has been added. It now has lead to this twisted monster. > Take a look at the fbdev driver codes in 2.4.X. Instead of another hack > the console system should be cleaned up with a well thought out design to > make the code base smaller and more effiencent. Where is the hack? The ppc64 early console code uses a hypervisor call or a serial port routine which have no business being in a generic console infrastructure. At the moment its two lines called before start_kernel to register the console, and 4 lines of disable_early_printk. We use existing routines to talk to the hypervisor or serial console. How is the reworked console system going to reduce this? :) Anton |
|
From: Andrew M. <ak...@di...> - 2002-10-13 21:23:15
|
Russell King wrote: > > On Sun, Oct 13, 2002 at 01:40:50PM -0700, James Simmons wrote: > > Ugh!!! The reason I reworked the console system is because over the years > > hack after hack has been added. It now has lead to this twisted monster. > > Take a look at the fbdev driver codes in 2.4.X. Instead of another hack > > the console system should be cleaned up with a well thought out design to > > make the code base smaller and more effiencent. > > There is a very good reason why stuff like this is needed. Its to get > the boot messages out of a non-booting box, when you know that its oopsed > before fbcon can be initialised. > > fbcon can't be initialised before PCI setup on many systems because the > PCI bus may not be setup, and therefore the VGA card may very well not > be accessible. > > I think you'll find that virtually every architecture has some method > to get real early boot time messages out of the box in some way (on ARM, > it involves enabling CONFIG_DEBUG_LL and adding a function call into > printk.c, and attaching a machine to a serial port - this works from > the moment that we start executing any kernel image.) > > You're not going to be able to design something to cover all cases. > Especially the ones where the normal C environment isn't up and running > yet. 8) Yes, there are a number of rude hacks down there to handle oopses and early startup. It's just a messy problem, and no solution to it will be a thing of beauty. And early printk is obviously a useful thing to have when the machine won't start. I think what we need James is just the low-level hook in printk.c which the various platforms and boards can plug into. The one in Martin's patch (module some cleanups, docco, conversion to C, etc) looks suitable to me. The actual early console drivers don't appear to have much relationship at all to the console layer really. They're just minimal-code busy-wait port banging. The patch needs to be split. - Generic part in printk.c. Make sure that it suits all users - ia32 serial early console driver - ia32 VGA early console driver. What else? And who's going to do it? |
|
From: Russell K. <rm...@ar...> - 2002-10-13 21:01:06
|
On Sun, Oct 13, 2002 at 01:40:50PM -0700, James Simmons wrote:
> Ugh!!! The reason I reworked the console system is because over the years
> hack after hack has been added. It now has lead to this twisted monster.
> Take a look at the fbdev driver codes in 2.4.X. Instead of another hack
> the console system should be cleaned up with a well thought out design to
> make the code base smaller and more effiencent.
There is a very good reason why stuff like this is needed. Its to get
the boot messages out of a non-booting box, when you know that its oopsed
before fbcon can be initialised.
fbcon can't be initialised before PCI setup on many systems because the
PCI bus may not be setup, and therefore the VGA card may very well not
be accessible.
I think you'll find that virtually every architecture has some method
to get real early boot time messages out of the box in some way (on ARM,
it involves enabling CONFIG_DEBUG_LL and adding a function call into
printk.c, and attaching a machine to a serial port - this works from
the moment that we start executing any kernel image.)
You're not going to be able to design something to cover all cases.
Especially the ones where the normal C environment isn't up and running
yet. 8)
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Martin J. B. <mb...@ar...> - 2002-10-13 20:53:38
|
>> > Are you going to have early console support (ie printk from before >> > what is now console_init) done before the freeze, or should I just >> > submit our version? >> >> On ppc64 Im currently setting a console up very early in arch init code >> and using the CONFIG_EARLY_PRINTK hook to disable it at console_init >> time. Works OK for me, do you guys need something on top of that? > > Ugh!!! The reason I reworked the console system is because over the years > hack after hack has been added. It now has lead to this twisted monster. > Take a look at the fbdev driver codes in 2.4.X. Instead of another hack > the console system should be cleaned up with a well thought out design to > make the code base smaller and more effiencent. Cool, as long as it gets merged by the freeze. We've been waiting for you to do this for a long time, but if it's not ready, then we need the hacky versions in order to get the functionality. M. |
|
From: James S. <jsi...@in...> - 2002-10-13 20:47:19
|
On Sat, 12 Oct 2002, Anton Blanchard wrote: > > > Are you going to have early console support (ie printk from before > > what is now console_init) done before the freeze, or should I just > > submit our version? > > On ppc64 Im currently setting a console up very early in arch init code > and using the CONFIG_EARLY_PRINTK hook to disable it at console_init > time. Works OK for me, do you guys need something on top of that? Ugh!!! The reason I reworked the console system is because over the years hack after hack has been added. It now has lead to this twisted monster. Take a look at the fbdev driver codes in 2.4.X. Instead of another hack the console system should be cleaned up with a well thought out design to make the code base smaller and more effiencent. |
|
From: Anton B. <an...@sa...> - 2002-10-13 00:06:39
|
> That reminds me. Has anyone noticed that sysrq on the serial console > is broken? Strange, its working fine on ppc64. Anton |
|
From: William L. I. I. <wl...@ho...> - 2002-10-12 19:26:45
|
On Sat, Oct 12, 2002 at 12:22:29PM -0700, Dave Hansen wrote: > That reminds me. Has anyone noticed that sysrq on the serial console > is broken? For so long I've not bothered trying. |
1998 messages has been excluded from this view by a project administrator.
