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: Johann D. <jo...@Do...> - 2001-12-04 14:13:16
|
On Tue, 4 Dec 2001, James Gibson wrote:
>
> On 3 Dec 2001, at 22:00, Jakob Eriksson wrote:
>
> > > On Sun, Dec 02, 2001 at 10:34:04PM +0100, Lorenzo Delana wrote:
> > >
> > > > > I think tuntitko uses the same license as XFree86, so that it
> > > > > could be merged in later. 0rfelyus should know.
> > > >
> > > > right I understand now, clearly all the things near to XFree86
> > > > should to be licensed under XFree86 license so the merge with it
> > > > is possible. So I'm accordly to use an XFree license.
> > > >
> > > > Ley me undertand... XFree86 license cannot merge with GPL parts in
> > > > any case ?
> > >
> > > Honestly, I'm not sure now. I think they could be compatible, but I
> > > don't remember the XFree86 license exactly. Anyway, you can't add
> > > GPL'd code to XFree86 without imposing GPL restrictions on XFree86
> > > as a whole.
> >
> > X11 licensed code can be integrated into GPL code.
> > Not the other way, then "the product as a whole" becomes GPL,
> > and the XFree86 people don't want that...
> >
> > X11 is very permitting, says basically; "do what you want.
> > We are not responsible for what happens."
> > Jakob
> I was looking into writing a module to replace the legacy keyboard
> support in X using the input specifications a while back.. I ran into
> the block we have here: I was able to sketch out some pseudo
> code, but never went any further when I realized I couldn't get by
> without pulling verbatim some struct{}s from the input headers in
> the linux kernel, specifically the structure of the input packets,
> etc..... is there possibly a design document that has this
> information in a license-neutral format that I could use instead of
> the kernel headers? Or am I okay using the structures? I never was
> able to get an info on this from the Xpert list....
I just realized something: XFree depends on the glibc, doesn't it ? As
does any program in Linux (even Netscape when it was closed-source).
I thought this was OK because the glibc was under LGPL, not GPL. I checked
om my system, and it seems the glibc is protected by the GPL, not
the LGPL. Has it allways been the case ?
That could be a really serious issue...
--
Johann Deneux
|
|
From: James G. <twi...@su...> - 2001-12-04 02:55:25
|
On 3 Dec 2001, at 22:00, Jakob Eriksson wrote:
> > On Sun, Dec 02, 2001 at 10:34:04PM +0100, Lorenzo Delana wrote:
> >
> > > > I think tuntitko uses the same license as XFree86, so that it
> > > > could be merged in later. 0rfelyus should know.
> > >
> > > right I understand now, clearly all the things near to XFree86
> > > should to be licensed under XFree86 license so the merge with it
> > > is possible. So I'm accordly to use an XFree license.
> > >
> > > Ley me undertand... XFree86 license cannot merge with GPL parts in
> > > any case ?
> >
> > Honestly, I'm not sure now. I think they could be compatible, but I
> > don't remember the XFree86 license exactly. Anyway, you can't add
> > GPL'd code to XFree86 without imposing GPL restrictions on XFree86
> > as a whole.
>
> X11 licensed code can be integrated into GPL code.
> Not the other way, then "the product as a whole" becomes GPL,
> and the XFree86 people don't want that...
>
> X11 is very permitting, says basically; "do what you want.
> We are not responsible for what happens."
> Jakob
I was looking into writing a module to replace the legacy keyboard
support in X using the input specifications a while back.. I ran into
the block we have here: I was able to sketch out some pseudo
code, but never went any further when I realized I couldn't get by
without pulling verbatim some struct{}s from the input headers in
the linux kernel, specifically the structure of the input packets,
etc..... is there possibly a design document that has this
information in a license-neutral format that I could use instead of
the kernel headers? Or am I okay using the structures? I never was
able to get an info on this from the Xpert list....
James Gibson
twi...@su...
|
|
From: Rogelio M. S. Jr. <ro...@vi...> - 2001-12-04 00:53:47
|
I get problems booting. Everything goes fine and stops just before the login. I dont get a login prompt. If i press some keys i get this: Unknown key (set 22, scancode 0x11d, on isa0060/serio0) pressed. Unknown key (set 22, scancode 0x11d, on isa0060/serio0) released. Only for some keys, the rest dont generate this message. I am using an olivetti keyboard. The model is ANK 27-101. It doesnt have the windblows keys. ctrl-alt-del doesnt reboot my machine. I have to cycle the power to restart. further up the log i have: [snipped...] Dec 4 08:23:30 coffeesaur kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Dec 4 08:23:30 coffeesaur kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 Dec 4 08:23:30 coffeesaur kernel: input: AT Set 22 keyboard on isa0060/serio0 [snipped...] |
|
From: Johann D. <jo...@Do...> - 2001-12-03 22:50:28
|
On Mon, 3 Dec 2001, Jakob Eriksson wrote: > > On Sun, Dec 02, 2001 at 10:34:04PM +0100, Lorenzo Delana wrote: > > > > > > I think tuntitko uses the same license as XFree86, so that it could be > > > > merged in later. 0rfelyus should know. > > > > > > right I understand now, clearly all the things near to XFree86 should to be > > > licensed under XFree86 license so the merge with it is possible. So I'm > > > accordly to use an XFree license. > > > > > > Ley me undertand... XFree86 license cannot merge with GPL parts in any case ? > > > > Honestly, I'm not sure now. I think they could be compatible, but I > > don't remember the XFree86 license exactly. Anyway, you can't add GPL'd > > code to XFree86 without imposing GPL restrictions on XFree86 as a whole. > > X11 licensed code can be integrated into GPL code. > Not the other way, then "the product as a whole" becomes GPL, > and the XFree86 people don't want that... Here comes another legal mystery (to my eyes, at least). How do you tell what code you incorporate into what code ? Of course, if we make a kind of XFree86-with-input-patch, it may seem that we incorporated some GPL code into some XFree86 code, but this is purely a view of mind. We could see it this way, too: "We have some piece of userland-code over the input drivers (under GPL). I would like to have a graphical interface, too. Hmm, how are we going to fill in the holes ? Hey, there is this soft, XFree86, which license says we can do what we want with the code. Let's take it !". And now we have incorporated XFree86 code into GPL code. Quite a twisted way of seeing things, but I do not see why it would not be valid. > > X11 is very permitting, says basically; "do what you want. > We are not responsible for what happens." > > > Jakob > -- Johann Deneux |
|
From: Jakob E. <ja...@vm...> - 2001-12-03 21:00:26
|
> On Sun, Dec 02, 2001 at 10:34:04PM +0100, Lorenzo Delana wrote: > > > > I think tuntitko uses the same license as XFree86, so that it could be > > > merged in later. 0rfelyus should know. > > > > right I understand now, clearly all the things near to XFree86 should to be > > licensed under XFree86 license so the merge with it is possible. So I'm > > accordly to use an XFree license. > > > > Ley me undertand... XFree86 license cannot merge with GPL parts in any case ? > > Honestly, I'm not sure now. I think they could be compatible, but I > don't remember the XFree86 license exactly. Anyway, you can't add GPL'd > code to XFree86 without imposing GPL restrictions on XFree86 as a whole. X11 licensed code can be integrated into GPL code. Not the other way, then "the product as a whole" becomes GPL, and the XFree86 people don't want that... X11 is very permitting, says basically; "do what you want. We are not responsible for what happens." Jakob |
|
From: Vojtech P. <vo...@su...> - 2001-12-02 22:15:11
|
On Sun, Dec 02, 2001 at 10:34:04PM +0100, Lorenzo Delana wrote:
> > I think tuntitko uses the same license as XFree86, so that it could be
> > merged in later. 0rfelyus should know.
>
> right I understand now, clearly all the things near to XFree86 should to be
> licensed under XFree86 license so the merge with it is possible. So I'm
> accordly to use an XFree license.
>
> Ley me undertand... XFree86 license cannot merge with GPL parts in any case ?
Honestly, I'm not sure now. I think they could be compatible, but I
don't remember the XFree86 license exactly. Anyway, you can't add GPL'd
code to XFree86 without imposing GPL restrictions on XFree86 as a whole.
> So LinuxConsole are divided in two parts:
> - kernel ( GPL code )
> - xfree ( XFree86 code )
>
> Are y accordly if I provide to the project the tintitko-40.c source code that
> remains todo ? I am working on it and I hope to finish in few days...
> In code writing I make sharing of all possible things with
> tintitko-{common,devconfig}...
Yes, that'd be wonderful.
--
Vojtech Pavlik
SuSE Labs
|
|
From: Lorenzo D. <ld...@li...> - 2001-12-02 21:37:17
|
On Sunday 02 December 2001 20:57, you wrote:
> On Sun, Dec 02, 2001 at 06:43:29PM +0100, Lorenzo Delana wrote:
> > I would write code for XFree4.0 of tuntitko, but before I start I would
> > to know under what type of license is tuntitko... I no see no
> > specification in the ruby/xfree86 CVS source code...
> >
> > I hope that all goes under GPL...
>
> I think tuntitko uses the same license as XFree86, so that it could be
> merged in later. 0rfelyus should know.
right I understand now, clearly all the things near to XFree86 should to be
licensed under XFree86 license so the merge with it is possible. So I'm
accordly to use an XFree license.
Ley me undertand... XFree86 license cannot merge with GPL parts in any case ?
So LinuxConsole are divided in two parts:
- kernel ( GPL code )
- xfree ( XFree86 code )
Are y accordly if I provide to the project the tintitko-40.c source code that
remains todo ? I am working on it and I hope to finish in few days...
In code writing I make sharing of all possible things with
tintitko-{common,devconfig}...
bye
Lore
|
|
From: Lorenzo D. <ld...@li...> - 2001-12-02 21:28:15
|
On Sunday 02 December 2001 19:03, you wrote: > Hi Lorenzo! > > > Definitively when serial/usb goes into Input Linux driver, an Xinput that > > reads from /dev/input/event0 makes works two version of this device. > > According to this page the kernel usb support is part of the linux-usb > project. I gathered the informations about Chris driver from this > list. I think if aiptek wents into the input directory then all other > input based drivers have at least to be considered to be put there as > well. I can't really say where it better fits, but at least the wacom > driver would fit as input device as well like the aiptek driver. > right, but consider that wacom is a project started when Linux Input infrastructure isn't already enabled... so Xinput was the only best solution for that time. Note that nowday LinuxConsole project have: - linux kernel part ( GPL license ) - xfree part ( XFree86 license ) and xfree part enable Linux Input => XInput interfacing, only for XFree86 3.3 release, but I am writing 4.0 ver and I hope to finish in few days. Seems that an XFree86 license is the best solution for parts of software that are near to the XFree itself, so a merge is possible... but if y think that is possible to make an linux input instead of an xinput for aiptek serial vers. y can license under GPL without problem. > So I basically agree, but it still should be discussed on the > linux-usb and the linuxconsole ML. > > Best regards, > > Reinhard |
|
From: James S. <jsi...@tr...> - 2001-12-02 07:10:26
|
> fb_info is missing in struct fb_info_aty128. > > Also serial_8250_pci.c and serial_8250_pnp.c fails at > MODULE_GENERIC_TABLE with "sizeof applied to an incomplete type". I cant > find a pci_id struct or a isapnp_id struct. All fixed. Sorry about not fixing the reboot problem yet. Right now I'm working on new console locking code due to what Alan Cox brought to light to me. It appears to be possible to have consoles without TTYs. The lpr console is a example. Also going threw all the console drivers I noticed the VT system is the only console/TTY system that calls register_tty_driver before register_console. So the VT system as usual is broken. So I'm working to fix that. Now the locking code has to handle 3 cases. 1) hardware driven by only the TTY layer 2) hardware driven by only the console layer. 3) hardware driver by both. |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2001-12-02 01:21:27
|
fb_info is missing in struct fb_info_aty128. Also serial_8250_pci.c and serial_8250_pnp.c fails at MODULE_GENERIC_TABLE with "sizeof applied to an incomplete type". I cant find a pci_id struct or a isapnp_id struct. |
|
From: James S. <jsi...@tr...> - 2001-12-01 16:46:58
|
> I get this kernel oops when doing a Ctrl-Alt-Del which almost always > occurs immediately after a Disk I/O operation. This is from the ruby > tree 24 hours ago. I'm not so sure how to go about this, so I'll just > post the oops-tracing. Finally a oops. I never have manged to get a oops. The only thing that happens is it just hangs for me :-/ Now I can fix that problem. Thank you. |
|
From: James S. <jsi...@tr...> - 2001-12-01 16:43:20
|
Here is a link to my patch for the new framebuffer api and the first change from it, the blank code cleanup. The patch is a good size (84K) but is need. Please apply it. It includes the first patch I sent you but I didn't see it applied so I included with this patch. Thank you. http://www.transvirtual.com/~jsimmons/blank.diff |
|
From: Antonino D. <ad...@po...> - 2001-12-01 09:12:40
|
Hi, I get this kernel oops when doing a Ctrl-Alt-Del which almost always occurs immediately after a Disk I/O operation. This is from the ruby tree 24 hours ago. I'm not so sure how to go about this, so I'll just post the oops-tracing. Tony -- start trace -- <4>cpu: 0, clocks: 1004299, slice: 502149 <1>Unable to handle kernel paging request at virtual address 5a5a5a5a <4>c018dc05 <1>*pde = 00000000 <4>Oops: 0000 <4>CPU: 0 <4>EIP: 0010:[<c018dc05>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 <4>EFLAGS: 00010006 <4>eax: cbc0b000 ebx: 5a5a5a5a ecx: 0000004b edx: cbedf0a8 <4>esi: c12fe000 edi: 0000f20c ebp: 00000080 esp: c0261e9c <4>ds: 0018 es: 0018 ss: 0018 <4>Process swapper (pid: 0, stackpage=c0261000) <4>Stack: 5a5a5a5a c018d14e 5a5a5a5a 00000002 c018d19b c12fe000 c018db0c c12fe000 <4> 0000000c 00000000 00000001 c13ed200 00000001 0000006f 0000000b c018db45 <4> c02baa40 0000006f 00000001 c01b704a cbedcd5c 00000001 0000006f 00000001 <4>Call Trace: [<c018d14e>] [<c018d19b>] [<c018db0c>] [<c018db45>] [<c01b704a>] <4> [<c01b89ae>] [<c01b85b7>] [<c01080fd>] [<c0108266>] [<c0105150>] [<c0105150>] <4> [<c0105150>] [<c0105150>] [<c0105173>] [<c01051d9>] [<c0105000>] [<c0105027>] <4>Code: 8b 03 85 c0 74 18 39 98 74 10 00 00 75 10 c7 80 74 10 00 00 >>EIP; c018dc04 <kbd_disconnect+4/40> <===== Trace; c018d14e <fn_boot_it+26/38> Trace; c018d19a <k_spec+2e/34> Trace; c018db0c <kbd_keycode+200/218> Trace; c018db44 <kbd_event+20/40> Trace; c01b704a <input_event+2ea/304> Trace; c01b89ae <atkbd_interrupt+19e/1ac> Trace; c01b85b6 <i8042_interrupt+b2/c8> Trace; c01080fc <handle_IRQ_event+30/5c> Trace; c0108266 <do_IRQ+6a/a8> Trace; c0105150 <default_idle+0/28> Trace; c0105150 <default_idle+0/28> Trace; c0105150 <default_idle+0/28> Trace; c0105150 <default_idle+0/28> Trace; c0105172 <default_idle+22/28> Trace; c01051d8 <cpu_idle+40/54> Trace; c0105000 <_stext+0/0> Trace; c0105026 <rest_init+26/28> Code; c018dc04 <kbd_disconnect+4/40> 00000000 <_EIP>: Code; c018dc04 <kbd_disconnect+4/40> <===== 0: 8b 03 mov (%ebx),%eax <===== Code; c018dc06 <kbd_disconnect+6/40> 2: 85 c0 test %eax,%eax Code; c018dc08 <kbd_disconnect+8/40> 4: 74 18 je 1e <_EIP+0x1e> c018dc22 <kbd_disconnect+22/40> Code; c018dc0a <kbd_disconnect+a/40> 6: 39 98 74 10 00 00 cmp %ebx,0x1074(%eax) Code; c018dc10 <kbd_disconnect+10/40> c: 75 10 jne 1e <_EIP+0x1e> c018dc22 <kbd_disconnect+22/40> Code; c018dc12 <kbd_disconnect+12/40> e: c7 80 74 10 00 00 00 movl $0x0,0x1074(%eax) Code; c018dc18 <kbd_disconnect+18/40> 15: 00 00 00 <4> <0>Kernel panic: Aiee, killing interrupt handler! -- end trace -- |
|
From: James S. <jsi...@tr...> - 2001-11-30 22:55:56
|
> I have also been trying to use the new patch but my video card seems to be > unsupported. I have a rage 128 pro ultra tf. Is it enough to modify the > aty128_pci_probe_list? Yes. Can you post the results of lspci -vvv. |
|
From: Rogelio M. S. Jr. <ro...@vi...> - 2001-11-30 22:48:24
|
I have also been trying to use the new patch but my video card seems to be unsupported. I have a rage 128 pro ultra tf. Is it enough to modify the aty128_pci_probe_list? On Fri, 30 Nov 2001, James Simmons wrote: > > > I just downloaded the ruby tree and tried it. It compiles without > > errors and the sytem boots okay. It seems that tty0 was used only for > > "printk" console dumps since I wasn't able to see a login prompt > > afterwards. I was able to switch to tty1 and login from there. Is this > > "normal" for the current snapshot? > > Yes. The standard tree is not multidesktop aware. So their is only one > foreground VC even when you have multiple heads. tty0 is always teh > foreground VC. Now in ruby it doesn't make sense to have /dev/tty0 as the > foreground console since their can be more than one of them. So instead > tty0 to tty15 goes to VT one and tty16 to tty31 goes to VT 2 etc. BTW > their is no such a thing at tty0 as the foreground VC on SYSV UNIXs. So > linux is broken in this way. > > To have a terminal on tty0 just add to /etc/inittab > > 1:2345:respawn:/sbin/mingetty tty0 > > and increment the numbers of the VCs that follow. Note for the standard > tree if you have this in your inittab the console will behave strangely. > > > Secondly, is the new framebuffer API already workable? > > Yes. It is pretty stable. The upper console stuff needs some work. > > > (aty128fb, pm3fb, vga16fb, etc). I tried vga16fb (only one that works > > for the i810 chipset), it fails to compile with "undefined reference to > > spinlock_init" although changing "spinlock_init" to "spin_lock_init" in > > vga16fb.c seems to correct the error (not sure if this is the correct > > way to do this). > > Oops. I haven't worked on that in some time. > > > I enabled "framebuffer console support" in the kernel > > config and rebooted. I just got a blank/corrupted screen though, and > > the machine never finished the booting and locks up at the end. Never > > got to log any debugging messages to a file. > > The rectfill, copyarea and image functions are broke for that driver. I > never got around to fixing. I will shortly. > > > I'm asking the above since while trying to write an i810 driver for the > > new API, I met the same problem as with the vga16fb. The "check_var" > > and "set_var" fb_ops seem to work since I was able to properly set the > > video mode using those functions during a test. I was able to directly > > write to info->screen_base and correctly display the pixel data. I was > > also able to use cfb_rectfill to display a 64x64 pixel square. > > > > Anything I might have missed or anything I need to examine more > > closely? > > Nope. The vga16fb driver needs some work. I will get to it. I just need a > rectfill, cooparea, and imageblit function for that driver. > > > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > > |
|
From: James S. <jsi...@tr...> - 2001-11-30 19:34:06
|
> I just downloaded the ruby tree and tried it. It compiles without > errors and the sytem boots okay. It seems that tty0 was used only for > "printk" console dumps since I wasn't able to see a login prompt > afterwards. I was able to switch to tty1 and login from there. Is this > "normal" for the current snapshot? Yes. The standard tree is not multidesktop aware. So their is only one foreground VC even when you have multiple heads. tty0 is always teh foreground VC. Now in ruby it doesn't make sense to have /dev/tty0 as the foreground console since their can be more than one of them. So instead tty0 to tty15 goes to VT one and tty16 to tty31 goes to VT 2 etc. BTW their is no such a thing at tty0 as the foreground VC on SYSV UNIXs. So linux is broken in this way. To have a terminal on tty0 just add to /etc/inittab 1:2345:respawn:/sbin/mingetty tty0 and increment the numbers of the VCs that follow. Note for the standard tree if you have this in your inittab the console will behave strangely. > Secondly, is the new framebuffer API already workable? Yes. It is pretty stable. The upper console stuff needs some work. > (aty128fb, pm3fb, vga16fb, etc). I tried vga16fb (only one that works > for the i810 chipset), it fails to compile with "undefined reference to > spinlock_init" although changing "spinlock_init" to "spin_lock_init" in > vga16fb.c seems to correct the error (not sure if this is the correct > way to do this). Oops. I haven't worked on that in some time. > I enabled "framebuffer console support" in the kernel > config and rebooted. I just got a blank/corrupted screen though, and > the machine never finished the booting and locks up at the end. Never > got to log any debugging messages to a file. The rectfill, copyarea and image functions are broke for that driver. I never got around to fixing. I will shortly. > I'm asking the above since while trying to write an i810 driver for the > new API, I met the same problem as with the vga16fb. The "check_var" > and "set_var" fb_ops seem to work since I was able to properly set the > video mode using those functions during a test. I was able to directly > write to info->screen_base and correctly display the pixel data. I was > also able to use cfb_rectfill to display a 64x64 pixel square. > > Anything I might have missed or anything I need to examine more > closely? Nope. The vga16fb driver needs some work. I will get to it. I just need a rectfill, cooparea, and imageblit function for that driver. |
|
From: James S. <jsi...@tr...> - 2001-11-30 19:18:21
|
This patch is pretty big. Basically it moves the blank function out of struct fb_info into struct fb_ops where it belongs. I makes it flexiable that if your hardware doesn't support blanking of any kind that you can leave this field NULL in struct fb_ops. At present if you don't supply a blank function it could oops (see where blank() is called in fbcon.c). Thus people are forced to supply a empty function. This saves that overhead of a function call for those drivers. I have tested it on my local machine for the past 24 hours. It works fine. I did a compile test for every driver that is avaliable on the ix86 thus those drivers do compile and most likely work. Please test this on other hardware platforms and across drivers. Since the patch is to big it is at the following link: http://www.transvirtual.com/~jsimmons/blank.diff Please note it also includes the patch I sent Linus earlier for fb.h. I will remove that part once that patch goes in. Thank you. |
|
From: James S. <jsi...@tr...> - 2001-11-30 17:46:41
|
Here is a patch that had Geert's blessing. This patch is to introduce a
new api for the frmaebuffer layer that will massively cleanup this
subsystem. Please apply. Thank you.
--- linux-2.5.0/include/linux/fb.h Wed Nov 28 16:43:10 2001
+++ linux/include/linux/fb.h Thu Nov 29 11:02:26 2001
@@ -241,6 +241,39 @@
__u32 reserved[4]; /* reserved for future compatibility */
};
+/* Internal HW accel */
+#define ROP_COPY 0
+#define ROP_XOR 1
+
+struct fb_copyarea {
+ __u32 sx; /* screen-relative */
+ __u32 sy;
+ __u32 width;
+ __u32 height;
+ __u32 dx;
+ __u32 dy;
+};
+
+struct fb_fillrect {
+ __u32 dx; /* screen-relative */
+ __u32 dy;
+ __u32 width;
+ __u32 height;
+ __u32 color;
+ __u32 rop;
+};
+
+struct fb_image {
+ __u32 width; /* Size of image */
+ __u32 height;
+ __u16 dx; /* Where to place image */
+ __u16 dy;
+ __u32 fg_color; /* Only used when a mono bitmap */
+ __u32 bg_color;
+ __u8 depth; /* Dpeth of the image */
+ char *data; /* Pointer to image data */
+};
+
#ifdef __KERNEL__
#if 1 /* to go away in 2.5.0 */
@@ -250,10 +283,10 @@
#endif
#include <linux/fs.h>
+#include <linux/poll.h>
#include <linux/init.h>
#include <linux/devfs_fs_kernel.h>
-
struct fb_info;
struct fb_info_gen;
struct vm_area_struct;
@@ -283,9 +316,25 @@
/* set colormap */
int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, int con,
struct fb_info *info);
- /* pan display (optional) */
- int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
- struct fb_info *info);
+ /* checks var and creates a par based on it */
+ int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);
+ /* set the video mode according to par */
+ int (*fb_set_par)(struct fb_info *info);
+ /* set color register */
+ int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp, struct fb_info *info);
+ /* blank display */
+ int (*fb_blank)(int blank, struct fb_info *info);
+ /* pan display */
+ int (*fb_pan_display)(struct fb_var_screeninfo *var, int con, struct fb_info *info);
+ /* draws a rectangle */
+ void (*fb_fillrect)(struct fb_info *p, struct fb_fillrect *rect);
+ /* Copy data from area to another */
+ void (*fb_copyarea)(struct fb_info *p, struct fb_copyarea *region);
+ /* Draws a image to the display */
+ void (*fb_imageblit)(struct fb_info *p, struct fb_image *image);
+ /* perform polling on fb device */
+ int (*fb_poll)(struct fb_info *info, poll_table *wait);
/* perform fb specific ioctl (optional) */
int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
unsigned long arg, int con, struct fb_info *info);
@@ -309,6 +358,7 @@
char *screen_base; /* Virtual address */
struct display *disp; /* initial display variable */
struct vc_data *display_fg; /* Console visible on this display */
+ int currcon; /* Current VC. */
char fontname[40]; /* default font name */
devfs_handle_t devfs_handle; /* Devfs handle for new name */
devfs_handle_t devfs_lhandle; /* Devfs handle for compat. symlink */
@@ -387,6 +437,9 @@
struct fb_info *info);
extern int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
struct fb_info *info);
+extern void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect);
+extern void cfb_copyarea(struct fb_info *p, struct fb_copyarea *region);
+extern void cfb_imageblit(struct fb_info *p, struct fb_image *image);
/*
* Helper functions
@@ -400,6 +453,7 @@
extern int fbgen_switch(int con, struct fb_info *info);
extern void fbgen_blank(int blank, struct fb_info *info);
+extern void fbgen2_set_disp(int con, struct fb_info *info);
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
|
|
From: Geert U. <ge...@li...> - 2001-11-30 08:45:53
|
On Thu, 29 Nov 2001, James Simmons wrote:
> > >From what you wrote I assume that cmap.start must be 0 and cmap.len
> > some length, and it must be always set, as otherwise it is impossible
> > to guess image/mask depth from it.
>
> [snip]...
>
> I figured the cursor stuff would be something to work out more. I
> shamefully stoled it from the sun fb implementation. I have another patch
> patch for fb.h which removes the cursor stuff until we work something out.
>
>
> Geert if I have your blessing on this I like to send it off to Linus.
You have ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Antonino D. <ad...@po...> - 2001-11-30 06:52:28
|
Hi, I just downloaded the ruby tree and tried it. It compiles without errors and the sytem boots okay. It seems that tty0 was used only for "printk" console dumps since I wasn't able to see a login prompt afterwards. I was able to switch to tty1 and login from there. Is this "normal" for the current snapshot? Secondly, is the new framebuffer API already workable? I looked at some of the specific driver codes and a few have already been ported (aty128fb, pm3fb, vga16fb, etc). I tried vga16fb (only one that works for the i810 chipset), it fails to compile with "undefined reference to spinlock_init" although changing "spinlock_init" to "spin_lock_init" in vga16fb.c seems to correct the error (not sure if this is the correct way to do this). I enabled "framebuffer console support" in the kernel config and rebooted. I just got a blank/corrupted screen though, and the machine never finished the booting and locks up at the end. Never got to log any debugging messages to a file. I'm asking the above since while trying to write an i810 driver for the new API, I met the same problem as with the vga16fb. The "check_var" and "set_var" fb_ops seem to work since I was able to properly set the video mode using those functions during a test. I was able to directly write to info->screen_base and correctly display the pixel data. I was also able to use cfb_rectfill to display a 64x64 pixel square. Anything I might have missed or anything I need to examine more closely? Thanks. Tony |
|
From: James S. <jsi...@tr...> - 2001-11-30 00:31:52
|
> But Linus prefers otherwise. USB input drivers will stay in drivers/usb, For a long time this will be the case. > AT keyboard et cetera may stay in drivers/char, or we can put them in > drivers/serio or we may be able to persuade Linus drivers/input is fine > for them. Same for joysticks possibly in drivers/gameport. Yuck. First thing we should do is move input in front of char in the Config.in files. I defintely want to move serio.c into drivers/input to end the insanity of the current system. I will make a patch tonight. |
|
From: Vojtech P. <vo...@su...> - 2001-11-30 00:21:34
|
On Thu, Nov 29, 2001 at 01:24:50PM -0800, James Simmons wrote: > > > > Vojtech should we start sending out input drivers to the LKML for testing > > > and intergration now. > > > > Yes! > > Yeah!!!!!! > > The only thing is the issue of where the drivers go. In drivers/input or > in drivers/char. You know I prefere driers/input. But Linus prefers otherwise. USB input drivers will stay in drivers/usb, AT keyboard et cetera may stay in drivers/char, or we can put them in drivers/serio or we may be able to persuade Linus drivers/input is fine for them. Same for joysticks possibly in drivers/gameport. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-11-29 21:24:58
|
> > Vojtech should we start sending out input drivers to the LKML for testing > > and intergration now. > > Yes! Yeah!!!!!! The only thing is the issue of where the drivers go. In drivers/input or in drivers/char. You know I prefere driers/input. |
|
From: Vojtech P. <vo...@su...> - 2001-11-29 20:56:48
|
On Thu, Nov 29, 2001 at 11:13:01AM -0800, James Simmons wrote: > Vojtech should we start sending out input drivers to the LKML for testing > and intergration now. Yes! -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2001-11-29 19:13:26
|
Vojtech should we start sending out input drivers to the LKML for testing and intergration now. |
1998 messages has been excluded from this view by a project administrator.
