You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <jsi...@in...> - 2003-02-16 16:41:00
|
> Attached is a patch (linux-2.5.61 + James' fbdev.diff) to update i810fb: > > 1. added suspend/resume hooks to pci_driver. This is needed to > save/recover GART mappings during suspends/resumes. These are also > necessary for swsusp (software suspend) to work. > > 2. Fix compilation warnings. Applied. |
|
From: James S. <jsi...@in...> - 2003-02-16 16:40:43
|
Applied. > The attached patch (linux-2.5.61 + James' fbdev.diff) fixes the following: > > 1. compile error because of missing scripts/pmntologo. Hm. I thought there was only a c file that generated a binary to. That shouldn't be missing. It might be a BK sync issue on my part. > 2. Break up of fb_show_logo() to fb_prepare_logo()/fb_show_logo() to fix > weird "double drawing" or the "single draw, erase in a flash" of the > logo. > > 3. Fixed all drivers affected by the (image.depth == 0) is color > expansion. |
|
From: James S. <jsi...@in...> - 2003-02-16 16:39:13
|
Applied. On 16 Feb 2003, Antonino Daplas wrote: > Attached is a patch (linux-2.5.61 + James' fbdev.diff) to fix the "green screen" problem on module load, > and compilation warnings. > > Tony > > > > |
|
From: James S. <jsi...@in...> - 2003-02-16 16:39:04
|
Applied. > Attached is a patch (linux-2.5.61 + James' fbdev.diff) to fix compile warnings. |
|
From: James S. <jsi...@in...> - 2003-02-16 16:29:50
|
Applied. 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: Antonino D. <ad...@po...> - 2003-02-16 11:13:06
|
On Sun, 2003-02-16 at 14:08, Antonino Daplas wrote:
> The attached patch (linux-2.5.61 + James' fbdev.diff) fixes the following:
>
> 1. compile error because of missing scripts/pmntologo.
>
> 2. Break up of fb_show_logo() to fb_prepare_logo()/fb_show_logo() to fix
> weird "double drawing" or the "single draw, erase in a flash" of the
> logo.
>
> 3. Fixed all drivers affected by the (image.depth == 0) is color
> expansion.
>
Here's an incremental diff to protect logo drawing code with an
#ifdef CONFIG_FB_LOGO
Tony
diff -Naur linux-2.5.61-fbdev/drivers/video/fbmem.c linux-2.5.61-ad/drivers/video/fbmem.c
--- linux-2.5.61-fbdev/drivers/video/fbmem.c 2003-02-16 11:08:40.000000000 +0000
+++ linux-2.5.61-ad/drivers/video/fbmem.c 2003-02-16 11:08:19.000000000 +0000
@@ -41,7 +41,6 @@
#include <asm/pgtable.h>
#include <linux/fb.h>
-#include <linux/linux_logo.h>
#ifdef CONFIG_FRAMEBUFFER_CONSOLE
#include "console/fbcon.h"
@@ -369,6 +368,9 @@
return n < 0 ? d >> -n : d << n;
}
+#ifdef CONFIG_FB_LOGO
+#include <linux/linux_logo.h>
+
static void __init fb_set_logocmap(struct fb_info *info,
const struct linux_logo *logo)
{
@@ -656,6 +658,10 @@
kfree(logo_new);
return fb_logo.logo->height;
}
+#else
+int fb_prepare_logo(struct fb_info *info) { return 0; }
+int fb_show_logo(struct fb_info *info) { return 0; }
+#endif /* CONFIG_FB_LOGO */
static int fbmem_read_proc(char *buf, char **start, off_t offset,
int len, int *eof, void *private)
|
|
From: Antonino D. <ad...@su...> - 2003-02-16 06:23:52
|
On Sun, 2003-02-16 at 14:09, Antonino Daplas wrote: > Attached is a rediff (linux-2.5.61 + James' fbdev.diff) to enable fbcon module unloading. > Oops. Please disregard the previous patch. Attached is an updated diff. Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-16 06:12:07
|
Attached is a rediff (linux-2.5.61 + James' fbdev.diff) to enable fbcon module unloading. Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-16 06:12:03
|
Attached is a patch (linux-2.5.61 + James' fbdev.diff) to update i810fb: 1. added suspend/resume hooks to pci_driver. This is needed to save/recover GART mappings during suspends/resumes. These are also necessary for swsusp (software suspend) to work. 2. Fix compilation warnings. Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-16 06:11:58
|
Attached is a patch (linux-2.5.61 + James' fbdev.diff) to fix the "green screen" problem on module load, and compilation warnings. Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-16 06:11:54
|
Attached is a patch (linux-2.5.61 + James' fbdev.diff) to fix compile warnings. Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-16 06:11:50
|
The attached patch (linux-2.5.61 + James' fbdev.diff) fixes the following: 1. compile error because of missing scripts/pmntologo. 2. Break up of fb_show_logo() to fb_prepare_logo()/fb_show_logo() to fix weird "double drawing" or the "single draw, erase in a flash" of the logo. 3. Fixed all drivers affected by the (image.depth == 0) is color expansion. Tony |
|
From: James S. <jsi...@in...> - 2003-02-14 23:27:32
|
Hi! Here is the new fbdev patch. It is big because of the new logo code.Many bug fixes. You can do a pull at bk://fbdev.bkbits.net/fbdev-2.5 The diff is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz The changes are arch/mips64/Kconfig | 4 arch/ppc/syslib/prom.c | 3 arch/ppc/syslib/prom_init.c | 28 arch/ppc64/kernel/prom.c | 27 drivers/char/vt.c | 8 drivers/video/Kconfig | 1 drivers/video/Makefile | 3 drivers/video/aty/atyfb_base.c | 6 drivers/video/aty/mach64_accel.c | 45 drivers/video/aty/mach64_ct.c | 356 +++--- drivers/video/aty/mach64_cursor.c | 4 drivers/video/aty/mach64_gx.c | 18 drivers/video/cfbcopyarea.c | 42 drivers/video/cfbfillrect.c | 12 drivers/video/cfbimgblt.c | 90 - drivers/video/console/fbcon.c | 60 - drivers/video/console/newport_con.c | 69 - drivers/video/fbmem.c | 142 +- drivers/video/fbmon.c | 3 drivers/video/hgafb.c | 9 drivers/video/i810/i810.h | 7 drivers/video/i810/i810_accel.c | 64 - drivers/video/i810/i810_main.c | 392 +------ drivers/video/i810/i810_main.h | 2 drivers/video/logo/Kconfig | 67 + drivers/video/logo/Makefile | 27 drivers/video/logo/logo.c | 100 + drivers/video/logo/logo_dec_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_linux_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_linux_mono.pbm | 202 +++ drivers/video/logo/logo_linux_vga16.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_mac_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_parisc_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_sgi_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_sun_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_superh_clut224.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/logo/logo_superh_mono.pbm | 202 +++ drivers/video/logo/logo_superh_vga16.ppm | 1603 +++++++++++++++++++++++++++++ drivers/video/maxinefb.c | 2 drivers/video/maxinefb.h | 37 drivers/video/modedb.c | 8 drivers/video/neofb.c | 81 + drivers/video/pmag-ba-fb.c | 2 drivers/video/pmag-ba-fb.h | 24 drivers/video/pmagb-b-fb.c | 2 drivers/video/pmagb-b-fb.h | 32 drivers/video/radeonfb.c | 1 drivers/video/riva/fbdev.c | 274 ++-- drivers/video/skeletonfb.c | 6 drivers/video/sstfb.c | 14 drivers/video/sstfb.h | 355 ------ drivers/video/tdfxfb.c | 4 drivers/video/tridentfb.c | 2 drivers/video/vga16fb.c | 100 - include/linux/fb.h | 18 include/linux/linux_logo.h | 1435 ------------------------- include/video/mach64.h | 61 + include/video/maxinefb.h | 37 include/video/pmag-ba-fb.h | 24 include/video/pmagb-b-fb.h | 32 include/video/sstfb.h | 355 ++++++ include/video/vga.h | 16 62 files changed, 16488 insertions(+), 2854 deletions(-) |
|
From: Kronos <kr...@kr...> - 2003-02-14 22:34:40
|
Il Wed, Feb 12, 2003 at 08:04:19PM +0000, James Simmons ha scritto: > > If I append a specific video mode I'll get "out of scan > > range" or "no signal" depending on the video mode. This is > > "video=radeon:640x480-16@85" (no signal): > > Ug. The default mode in the modeb must be not supported by your card. Can > you try lowering the value for 85. I tried 75, 70, 60 without success. Btw both monitor and video card can handle 640x480@85Hz (the monitor can go up to 100Hz). Luca -- Reply-To: kr...@kr... Home: http://kronoz.cjb.net |
|
From: <hen...@ar...> - 2003-02-14 19:57:11
|
Hello! Virtual Framebuffer for monochrome embedded LCD with Epson controller SED1335 (S1D13305) are available. ftp://ssv-embedded.de/ssv/products/trm916/sample/x86/linux/fbdev/ Routines using monochrome RAM of CPU or Pseudocolor RAM and update this to LCD hardware in timer interval. This is a special embedded application. But all other users can use this skelet for other LC displays without memory mapped video ram. Such a graphic LCD on LPT port. In this case, I hope you will not delete the monochrome LOGO in your new logo code! Henry Gruss Hen...@Bi...---------------------------------------------------------------------------- Schlagen Sie sofort zu - mit Arcor und eBay Viele Artikel zum Sofort Kaufen! http://www.arcor.de/auk/ebay_sk.php ----------------------------------------------------------------------- |
|
From: Geert U. <ge...@li...> - 2003-02-14 09:25:26
|
On Fri, 14 Feb 2003, Leif Neland wrote:
> From: "James Simmons" <jsi...@in...>
> > > I have set up my primary work machine (i.e. it is mostly used as a
> terminal
> > > to connect to other servers) with framebuffer and have 64 lines*160
> chars in
> > > a pretty font.
> > >
> > > I ssh to other servers from this machine.
> > >
> > > If I do something which create a lot of output, eg. ls -lR /, the remote
> > > machine sends more data than the framebuffer-terminal can handle. This
> > > blocks the network on the terminal machine, which also is nameserver,
> > > internal webserver and upsd server.
>
> > Which kernel are you using and whcih video card?
>
> Debian-version: 3.0
>
> Linux 2.2.19
In 2.2.19, the console subsystem disables interrupts when outputting to the
console. This was fixed in 2.4.x.
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...> - 2003-02-14 05:29:38
|
Hi James,
Although fbcon can be compiled as a module, it cannot be safely unloaded
yet. If fbcon is unloaded, it typically results in a frozen box.
Allowing fbcon to successfully unload may be not so useful with typical
usage, but will be very helpful for developers. So here's a preliminary
patch to allow unloading of fbcon.
The main logic of the patch is when a console driver calls
take_over_console(), 'conswitchp' will be saved to 'defcsw'. When it
calls give_up_console() later on, aside from just unmapping the console
driver (which is what the original code does), it will also attempt to
reinstall the default console using the saved 'defcsw'pointer.
To minimize complexity, only one driver will be allowed to 'take over'
the console at a time. Succeeding calls to take_over_console() will
fail unless the driver gives up the console.
I made this a kernel config option, marked DANGEROUS. Also, only drivers
with an info->fbops->fb_release() hook will be allowed to unload. The
fb_release() hook need not do anything. Currently, fbcon on top of
vga16fb, rivafb or i810fb can be unloaded. I have tested this using
dummycon and vgacon.
Upon unload, the restored console will be partially corrupted. Also, I
think unicode mapped characters are not fully restored.
Any comments welcome.
Tony
diff -Naur linux-2.5.59-orig/drivers/char/vt.c linux-2.5.59/drivers/char/vt.c
--- linux-2.5.59-orig/drivers/char/vt.c 2003-02-14 02:43:42.000000000 +0000
+++ linux-2.5.59/drivers/char/vt.c 2003-02-14 03:15:50.000000000 +0000
@@ -109,6 +109,7 @@
const struct consw *conswitchp;
+const struct consw *defcsw = NULL; /* for recovery of default console */
/* A bitmap for codes <32. A bit of 1 indicates that the code
* corresponding to that bit number invokes some special action
@@ -2571,10 +2572,14 @@
int i, j = -1;
const char *desc;
+ if (deflt && defcsw != NULL)
+ return;
desc = csw->con_startup();
if (!desc) return;
- if (deflt)
+ if (deflt) {
+ defcsw = conswitchp;
conswitchp = csw;
+ }
for (i = first; i <= last; i++) {
int old_was_color;
@@ -2616,11 +2621,78 @@
void give_up_console(const struct consw *csw)
{
- int i;
+ const char *desc;
+ int i, j = -1, first = -1, last = -1;
- for(i = 0; i < MAX_NR_CONSOLES; i++)
- if (con_driver_map[i] == csw)
+ for(i = 0; i < MAX_NR_CONSOLES; i++) {
+ if (con_driver_map[i] == csw) {
+ if (first == -1)
+ first = i;
+ last = i;
con_driver_map[i] = NULL;
+ }
+ }
+
+ if (defcsw == NULL)
+ return;
+ conswitchp = defcsw;
+ defcsw = NULL;
+
+ desc = conswitchp->con_startup();
+ if (!desc) return;
+
+ for (i = first; i <= last; i++) {
+ int old_was_color;
+ int currcons = i;
+
+ con_driver_map[i] = conswitchp;
+
+ if (!vc_cons[i].d || !vc_cons[i].d->vc_sw)
+ continue;
+ j = i;
+ if (IS_VISIBLE)
+ save_screen(i);
+ old_was_color = vc_cons[i].d->vc_can_do_color;
+ vc_cons[i].d->vc_sw->con_deinit(vc_cons[i].d);
+ visual_init(i, 0);
+ set_origin(i);
+
+ /*
+ * partial reset_terminal()
+ */
+ top = 0;
+ bottom = video_num_lines;
+ gotoxy(i, x, y);
+ save_cur(i);
+ update_attr(i);
+
+
+ /* If the console changed between mono <-> color, then
+ * the attributes in the screenbuf will be wrong. The
+ * following resets all attributes to something sane.
+ */
+ if (old_was_color != vc_cons[i].d->vc_can_do_color ||
+ IS_VISIBLE)
+ clear_buffer_attributes(i);
+
+ if (IS_VISIBLE)
+ update_screen(i);
+ if (vc_cons[i].d->vc_tty) {
+ kill_pg(vc_cons[i].d->vc_tty->pgrp, SIGWINCH, 1);
+ vc_cons[i].d->vc_tty->winsize.ws_col =
+ video_num_columns;
+ vc_cons[i].d->vc_tty->winsize.ws_row =
+ video_num_lines;
+ }
+ }
+ printk("Console: switching ");
+ if (j >= 0)
+ printk("to %s %s %dx%d\n",
+ vc_cons[j].d->vc_can_do_color ? "colour" : "mono",
+ desc, vc_cons[j].d->vc_cols, vc_cons[j].d->vc_rows);
+ else
+ printk("to %s\n", desc);
+
}
#endif
diff -Naur linux-2.5.59-orig/drivers/video/console/Kconfig linux-2.5.59/drivers/video/console/Kconfig
--- linux-2.5.59-orig/drivers/video/console/Kconfig 2003-02-14 02:50:50.000000000 +0000
+++ linux-2.5.59/drivers/video/console/Kconfig 2003-02-14 04:35:01.000000000 +0000
@@ -106,6 +106,19 @@
tristate "Framebuffer Console support"
depends on FB
+config FRAMEBUFFER_CONSOLE_UNLOAD
+ bool "Allow Framebuffer Console Module Unloading (DANGEROUS)"
+ depends on FRAMEBUFFER_CONSOLE=m
+ default n
+ ---help---
+ If you say Y, the framebuffer console module can be unloaded
+ and the console reverted to the default console driver that was
+ loaded at boot time. Not all drivers support unloading, and even
+ if it does, it might leave you with a corrupted display.
+
+ Unless you are a framebuffer driver developer, or you really know
+ what you're doing, say N here.
+
config PCI_CONSOLE
bool
depends on FRAMEBUFFER_CONSOLE
diff -Naur linux-2.5.59-orig/drivers/video/console/fbcon.c linux-2.5.59/drivers/video/console/fbcon.c
--- linux-2.5.59-orig/drivers/video/console/fbcon.c 2003-02-14 02:44:46.000000000 +0000
+++ linux-2.5.59/drivers/video/console/fbcon.c 2003-02-14 03:00:19.000000000 +0000
@@ -202,6 +202,23 @@
static void fbcon_bmove_rec(struct display *p, int sy, int sx, int dy,
int dx, int height, int width, u_int y_break);
+/*
+ * fbcon module unloading
+ */
+
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_UNLOAD
+static void __init fbcon_mod_unload(struct fb_info *info)
+{
+ if (!info->fbops->fb_release)
+ __unsafe(THIS_MODULE);
+}
+#else
+static void __init fbcon_mod_unload(struct fb_info *info)
+{
+ __unsafe(THIS_MODULE);
+}
+#endif /* CONFIG_FRAMEBUFFER_CONSOLE_UNLOAD */
+
#ifdef CONFIG_MAC
/*
* On the Macintoy, there may or may not be a working VBL int. We need to probe
@@ -585,7 +602,7 @@
struct fb_info *info;
struct vc_data *vc;
static int done = 0;
- int irqres = 1;
+ int irqres = 1, i;
/*
* If num_registered_fb is zero, this is a call for the dummy part.
@@ -595,8 +612,11 @@
return display_desc;
done = 1;
- info = registered_fb[num_registered_fb-1];
- if (!info) return NULL;
+ for (i = 0; i < FB_MAX; i++) {
+ info = registered_fb[i];
+ if (info != NULL)
+ break;
+ }
info->currcon = -1;
owner = info->fbops->owner;
@@ -2562,19 +2582,86 @@
int __init fb_console_init(void)
{
+ struct fb_info *info = NULL;
+ int i, unit = 0;
+
if (!num_registered_fb)
return -ENODEV;
+ for (i = 0; i < FB_MAX; i++) {
+ info = registered_fb[i];
+ if (info != NULL) {
+ unit = i;
+ break;
+ }
+ }
+ for (i = 0; i < MAX_NR_CONSOLES; i++)
+ con2fb_map[i] = unit;
take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
+ fbcon_mod_unload(info);
+ return 0;
+}
+
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_UNLOAD
+static int __exit fbcon_exit(void)
+{
+ struct fb_info *info;
+ int i, j, mapped;
+
+ for (i = 0; i < FB_MAX; i++) {
+ info = registered_fb[i];
+ if (info != NULL && !info->fbops->fb_release)
+ return -EINVAL;
+ }
+
+ del_timer_sync(&cursor_timer);
+#ifdef CONFIG_AMIGA
+ if (MACH_IS_AMIGA)
+ free_irq(IRQ_AMIGA_VERTB, fbcon_vbl_handler);
+#endif /* CONFIG_AMIGA */
+#ifdef CONFIG_ATARI
+ if (MACH_IS_ATARI)
+ free_irq(IRQ_AUTO_4, fbcon_vbl_handler);
+#endif /* CONFIG_ATARI */
+#ifdef CONFIG_MAC
+ if (MACH_IS_MAC && vbl_detected)
+ free_irq(IRQ_MAC_VBL, fbcon_vbl_handler);
+#endif /* CONFIG_MAC */
+#if defined(__arm__) && defined(IRQ_VSYNCPULSE)
+ free_irq(IRQ_VSYNCPULSE, fbcon_vbl_handler);
+#endif
+ if (softback_buf)
+ kfree((void *) softback_buf);
+
+ for (i = 0; i < FB_MAX; i++) {
+ mapped = 0;
+ info = registered_fb[i];
+ if (info == NULL)
+ continue;
+ for (j = 0; j < MAX_NR_CONSOLES; j++) {
+ if (con2fb_map[j] == i) {
+ con2fb_map[j] = -1;
+ mapped = 1;
+ }
+ }
+ if (mapped) {
+ info->fbops->fb_release(info, 0);
+ module_put(info->fbops->owner);
+ kfree(info->display_fg);
+ }
+ }
return 0;
}
void __exit fb_console_exit(void)
{
+ if (fbcon_exit())
+ return;
give_up_console(&fb_con);
}
+module_exit(fb_console_exit);
+#endif /* CONFIG_FRAMEBUFFER_CONSOLE_UNLOAD */
module_init(fb_console_init);
-module_exit(fb_console_exit);
/*
* Visible symbols for modules
diff -Naur linux-2.5.59-orig/drivers/video/vga16fb.c linux-2.5.59/drivers/video/vga16fb.c
--- linux-2.5.59-orig/drivers/video/vga16fb.c 2003-02-14 02:43:49.000000000 +0000
+++ linux-2.5.59/drivers/video/vga16fb.c 2003-02-14 03:06:33.000000000 +0000
@@ -305,7 +305,8 @@
if (!cnt) {
memset(&par->state, 0, sizeof(struct vgastate));
- par->state.flags = 8;
+ par->state.flags = VGA_SAVE_FONTS | VGA_SAVE_MODE |
+ VGA_SAVE_CMAP;
save_vga(&par->state);
}
atomic_inc(&par->ref_count);
|
|
From: Leif N. <le...@ne...> - 2003-02-14 01:13:09
|
----- Original Message -----
From: "James Simmons" <jsi...@in...>
To: "Geert Uytterhoeven" <ge...@li...>
Cc: "Linux Frame Buffer Device Development"
<lin...@li...>; "Leif Neland" <le...@ne...>
Sent: Wednesday, February 12, 2003 9:01 PM
Subject: Re: [Linux-fbdev-devel] Framebuffer overflow halts network (fwd)
> > I have set up my primary work machine (i.e. it is mostly used as a
terminal
> > to connect to other servers) with framebuffer and have 64 lines*160
chars in
> > a pretty font.
> >
> > I ssh to other servers from this machine.
> >
> > If I do something which create a lot of output, eg. ls -lR /, the remote
> > machine sends more data than the framebuffer-terminal can handle. This
> > blocks the network on the terminal machine, which also is nameserver,
> > internal webserver and upsd server.
> >
> Which kernel are you using and whcih video card?
Debian-version: 3.0
Linux 2.2.19
From dmesg:
Detected 350798 kHz processor.
vesafb: framebuffer at 0xdc000000, mapped to 0xd0000000, size 4096k
vesafb: mode is 1280x1024x8, linelength=1280, pages=2
vesafb: protected mode interface info at c000:5b6a
vesafb: scrolling: redraw
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
from /proc/pci
Bus 0, device 12, function 0:
VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 1).
Medium devsel. IRQ 11. Master Capable. Latency=32. Min Gnt=4.Max
Lat=255.
Non-prefetchable 32 bit memory at 0xdc000000 [0xdc000000].
>
|
|
From: Geert U. <ge...@li...> - 2003-02-13 09:58:38
|
On Wed, 12 Feb 2003, Geert Uytterhoeven wrote:
> On Wed, 12 Feb 2003, James Simmons wrote:
> > > > > All comments are welcomed! Thanks!
> > > >
> > > > Come on, is there really no one to comment on this??
> > >
> > > Except a question why it's not merged yet? :)
> >
> > Looking for work has keot me busy. I merged it. One change I did do was
> > changed the CONFIG_FB_LOGO_* to CONFIG_LOGO_. In theory any one can use
> > the logo (i.e newport console). It is a much welcomed improvement. I
>
> OK.
BTW, most of the logo drawing is still not protected by CONFIG_(FB_)_LOGO. This
needs to change before it's submitted to Linus.
And why is the logo drawn from fbcon_switch() (which is not __init)? Does this
also explain why it's drawn twice (at least on some fbdevs)?
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: Geert U. <ge...@li...> - 2003-02-13 09:34:17
|
On 13 Feb 2003, Antonino Daplas wrote:
> On Thu, 2003-02-13 at 04:50, James Simmons wrote:
> > > > 1. Changed meaning of image.depth. If image.depth == 0, it flags for
> > > > color expansion, otherwise, it flags for image drawing (without color
> > > > expansion). This change is to accomodate monochrome cards so they can
> > > > differentiate character drawing from logo drawing.
> > >
> > > What's the status of this issue? Monochrome is still broken due to this.
>
> How about assigning fb_image.{bg_color,fg_color} to -1 if not color
> expanding? Since the pseudo_palette will not exceed 255, this should be
> safe.
Unless we ever want to support colors > 256 (or real pixel values)?
Alternatively, we can split imageblit in two routines, one for image drawing,
and one for color expansion.
So we now have 3 options:
1. image.depth = 0 means color expansion,
2. fb_image.{bg_color,fg_color} = -1 means color expansion,
3. separate functions for image drawing and color expansion.
I still favor solution 1, since image.depth = 0 is not possible for images,
while fb_image.{bg_color,fg_color} = -1 (= 0xffffffff) may become valid in the
future, and the last one is more work to adapt the current drivers.
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: WILLIAMS M. <mak...@ne...> - 2003-02-13 07:52:49
|
FROM:WILLIAMS MAKO Good day, You may be surprised to receive this letter from me since you do not know me personally. The purpose of my introduction is that I am williams mako, the first son of Zuma mako one of the most popular black farmer in Zimbabwe who was recently murdered in the land dispute in my country. I got your contact through network online hence decided to write you. Before the death of my father, he had taken me to Johannesburg to deposit the sum of USD$14.5 million (Fourteen million, Five Hundred thousand United Statesdollars), in one of the private security company, as he foresaw the looming danger in Zimbabwe this money was deposited in a box as gem stones to avoid much demurrage from security company. This amount was meant for the purchase of new machines and chemicals for the Farms and establishment of new farms in swaziland. This land problem came when Zimbabwean President Mr. Robert Mugabe introduced a new Land Act Reform wholly affecting the rich white farmers and some few black farmers, and this resulted to the killing and mob action by Zimbabwean war veterans and some lunatics in the society. In fact a lot of people were killed because of this Land reform Act for which my father was one of the victims. It is against this background that, I and my family fled Zimbabwe for fear of our lives and are currently staying in the Netherlands where we are seeking political asylum and moreso have decided to transfer my fathers money to a more reliable foreign account. since the law of Netherlands prohibits a refugee (asylum seeker) to open any bank account or to be involved in any financial transaction throughout the territorial zone of Netherlands, As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where this money could be transferred without the knowledge of my government who are bent on taking everything we have got. The South African government seems to be playing along with them. I am faced with the dilemma of moving this amount of money out of South Africa for fear of going through the same experience in future, both countries have similar political history. As a businessman,I am seeking for a partner who I have to entrust my future and that of my family in his hands, I must let you know that this transaction is risk free. If you accept to assist me and my family, all I want you to do for me, is to make an arrangements with the security company to clear the consignment(funds) from their affiliate office here in the Netherlands as i have already given directives for the consignment to be brought to the Netherlands from South Africa.But before then all modalities will have to be put in place like change of ownership to the consignment and more importantly this money I intend to use for investment. I have two options for you. Firstly you can choose to have certain percentage of the money for nominating your account for this transaction. Or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, feel free to notify me. I have also mapped out 5% of this money for all kinds of expenses incurred in the process of this transaction.If you do not prefer a partnership I am willing to give you 10% of the money while the remaining 85% will be for my investment in your country. Contact me with the above E-mail addresse,while I implore you to maintain the absolute secrecy required in this transaction. Thanks, GOD BLESS Yours Faithfully, Mr williams mako |
|
From: Russell K. <rm...@ar...> - 2003-02-12 23:56:25
|
On Wed, Feb 12, 2003 at 08:26:10PM +0000, James Simmons wrote:
> > So it looks like something isn't limiting the yoffset in the generic
> > console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> > is just nonsense.
>
> I'm going to need to do some heavy cleaning in the next few days.
>
> > I also noticed an additional problem with fbcon: if I change the
> > resolution using fbset, the change occurs, except I end up with
> > corrupted mess on the screen (the reminents of the original display.)
> > The shell prompt is nowhere to be seen.
> >
> > Hitting ^L clears the screen and then the shell prompt is visiable.
>
> The method to use now is stty to change the console mode. It works :-)
> fbset is used to change the variable the vt terminals are not familiar
> with such as bpp.
How do I ensure that such parameters as the refresh rate, hsync width and
offset, vsync width and offset are too my liking?
I've noticed that there seems to be some variation between the parameters
used, and I'd prefer to use my set since they match the host OS (it means
I don't have to keep readjusting the screen each time I change OS.)
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Antonino D. <ad...@po...> - 2003-02-12 23:37:37
|
On Thu, 2003-02-13 at 04:50, James Simmons wrote:
>
> > > 1. Changed meaning of image.depth. If image.depth == 0, it flags for
> > > color expansion, otherwise, it flags for image drawing (without color
> > > expansion). This change is to accomodate monochrome cards so they can
> > > differentiate character drawing from logo drawing.
> >
> > What's the status of this issue? Monochrome is still broken due to this.
>
How about assigning fb_image.{bg_color,fg_color} to -1 if not color
expanding? Since the pseudo_palette will not exceed 255, this should be
safe.
> Ug. There are a few issues left to deal with.
>
> 1) The cursor issue. We need to add in the cusor ioctl call for people to
> use. Theortically there should be no issues with using soft_cursor with
> full color images with xxfb_imageblit. I like to see dest go away in
In order to do this, fb_imageblit has to support transparency (using a
transparency bitmask). Userland apps will rarely have rectangular mouse
cursor pointers. Also, it will need to support ROP's invert and copy.
This will break fb_imageblit.
Also, we have to double-buffer what's underneath the cursor.
Tony
|
|
From: Antonino D. <ad...@po...> - 2003-02-12 23:37:30
|
On Thu, 2003-02-13 at 01:46, James Simmons wrote: > > > No one's commented on this yet. > > > > James? > > Sorry about the silence. The last month I have been devoting all my time > to look for work. As of next month I will be out of money. Meaning no home > to live in thus no internet. Because of this I like to have someone This is unfortunate :-( > replace me. Antonino you have done some really great work. I like you to > replace me to work with Geert to further the framebuffer layer. I still > have a month left to live on so I will contribute as much as I can. Thank > you. > I would like to help as much as I can with the development. However, I won't be able to manage the BK repository since I don't have broadband access (cannot recover from a failed bk clone). It's best if you leave this to someone who can. I'll be of better help if we can populate the CVS repository in sourceforge? Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-12 23:37:28
|
On Thu, 2003-02-13 at 04:15, James Simmons wrote: > > > > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it > > > works. > > > > > > > I haven't tried this yet, but I think it will work. The only (very > > minor) problem with this is the rivafb's printk output will be incorrect > > (no info on video memory size). > > True. All to keep in sync with X :-( Maybe we should break nv_driver.c > syncing since it already has been altered. Hell with it. Could you update > a patch with seperate functions for memsize clock finding. > Will do once you provide an updated patch I can diff against. Tony |