Re: [Linux-fbdev-devel] [PATCH] print an explanation why i810 fb doesn't come up
On Monday 28 March 2005 20:30, Denis Vlasenko wrote: > I've spent silly amonunt of time trying to use i810 fb on my new spiffy > flat panel. This patch will hopefully help other poor souls. > > Patch also fixes module parameter comments. Thanks, should help. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/video/intelfb/intelfbdrv.h
On Friday 15 April 2005 08:48, Adrian Bunk wrote: > Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes > for static functions - and such prototypes don't belong into header > files. > > This patch therefore removes drivers/video/intelfb/intelfbdrv.h and > moves the prototypes to intelfbdrv.c . > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Patch is linewrapped. Can you resend? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [Fwd: Console locking and blanking]
Alejandro Bonilla Beeche wrote: On Tue, 2005-08-16 at 23:44 -0400, Steven Rostedt wrote: On Wed, 2005-08-17 at 13:29 +1000, Benjamin Herrenschmidt wrote: On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: (I'm blind and I use a braille display. I use those functions to blank my laptop's screen so people don't read it, and hopefully to conserve power.) At the OLS I learned that the backlight of a laptop (when the screen is black, but still glows) actually spends more wattage than when the screen is lit. So, unless you actually turn the laptop display off, switching it to black will actually burn the battery quicker. This sounds stupid. Who told you this? The actual brightness is the one that consumes the most battery. Seriously, who told you such thing? In TFT displays, nontransmissive pixels consume more power than transmissive pixels. So a black background consumes more power than a white one. And if you are using these ioctl's to blank the screen, it will default to "normal blank" (if you don't set the vesa blanking mode first), which, in vgacon or most of the fbdev's, will just turn the color palette to all black. So yes, you might be consuming more power with this method. You're probably better off turning the brightness down, if you cannot turn the backlight off. Tony PS: I don't know the resulting power consumption if you use the vesa blanking modes (TIOCL_SETVESABLANK) to blank while leaving the backlight on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Jon Smirl wrote:
On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
On Wed, 27 Jul 2005, Linux Kernel Mailing List wrote:
There are a couple of ways to fix this.
1) Add a check to limit use of the sysfs attributes to 256 entries. If
you want more you have to use /dev/fb0 and the ioctl. More is an
uncommon case.
2) Switch this to a binary parameter. Now you have to use tools like
hexdump instead of cat to work with the data. It was nice to be able
to use cat to see the current map.
Does anyone have preferences for which way to fix it?
Or...
3) Add another file in sysfs which specifies at what index and how many
entries will be read or written from or to the cmap. With this additional
sysfs file, it should be able to handle any reasonable cmap length, but
it will take more than one reading of the color_map file. Another
advantage is that the entire color map need not be read or written if
only one field needs to be changed.
I've attached a test patch. Let me know what you think.
Tony
The functions store_cmap and show_cmap assume that cmap entries will never
exceed 256. However, even on the i386 graphics cards exist with 10-bit
DAC's. The current functions are insufficient on these hardware.
In order to provide support > 256 entries, a new sysfs entry is introduced -
cmap_range. It consists of two fields separated by a comma. The first field
sets the starting index, and the second field, the number of entries. Thus,
to grab a 256 color map in a machine with pagesize = 4096, one might do
the ff:
echo 0,128 > cmap_entry
cat color_map
echo 128,128 > cmap_entry
cat color_map
It also makes the function more efficient since one can alter a single entry
without reading/writing the entire cmap.
The output of color_map is also changed to accomodate the transparency field,
and also to increase readability.
.
.
where i = index;
t = transparency;
r = red;
g = green;
b = blue;
From: Antonino Daplas <[EMAIL PROTECTED]>
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
drivers/video/fbsysfs.c | 172
include/linux/fb.h |2
2 files changed, 117 insertions(+), 57 deletions(-)
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -242,95 +242,152 @@ static ssize_t show_virtual(struct class
fb_info->var.yres_virtual);
}
-/* Format for cmap is "%02x%c%4x%4x%4x\n" */
-/* %02x entry %c transp %4x red %4x blue %4x green \n */
-/* 255 rows at 16 chars equals 4096 */
-/* PAGE_SIZE can be 4096 or larger */
+/* Format for cmap is "%4x. %4x %4x %4x %4x\n" */
+/* %4x. index %4x transp %4x red %4x green %4x blue \n */
static ssize_t store_cmap(struct class_device *class_device, const char *buf,
size_t count)
{
- struct fb_info *fb_info = (struct fb_info
*)class_get_devdata(class_device);
- int rc, i, start, length, transp = 0;
-
- if ((count > 4096) || ((count % 16) != 0) || (PAGE_SIZE < 4096))
- return -EINVAL;
+ struct fb_info *fb_info = class_get_devdata(class_device);
+ int rc = 0, i, length, start = fb_info->cmap_start;
if (!fb_info->fbops->fb_setcolreg && !fb_info->fbops->fb_setcmap)
return -EINVAL;
- sscanf(buf, "%02x", &start);
- length = count / 16;
+ length = count/26;
- for (i = 0; i < length; i++)
- if (buf[i * 16 + 2] != ' ')
- transp = 1;
+ if (start + length > fb_info->cmap.len || length > fb_info->cmap_len)
+ return -EINVAL;
+ acquire_console_sem();
+
/* If we can batch, do it */
if (fb_info->fbops->fb_setcmap && length > 1) {
struct fb_cmap umap;
memset(&umap, 0, sizeof(umap));
- if ((rc = fb_alloc_cmap(&umap, length, transp)))
- return rc;
- umap.start = start;
- for (i = 0; i < length; i++) {
- sscanf(&buf[i * 16 + 3], "%4hx", &umap.red[i]);
- sscanf(&buf[i * 16 + 7], "%4hx", &umap.blue[i]);
- sscanf(&buf[i * 16 + 11], "%4hx", &umap.green[i]);
- if (transp)
- umap.transp[i] = (buf[i * 16 + 2] != ' ');
+ rc = fb_alloc_cmap(&umap, length, 1);
+
+ if (!rc) {
+ umap.start = start;
+
+ for (i = 0; i < length; i++) {
+ sscanf(&buf[i*26+06], "%4hx", &umap.transp[i]);
+ sscanf(&buf[i*26+11], "%4hx", &umap.red[i]);
+ sscanf(&buf[i*26+16], "%4hx", &umap.green[i]);
+ sscanf(&buf[i*26+21], "%4hx", &umap.blue[i]);
+
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Jon Smirl wrote: Can you review this fix for the issues below? I fixed things to automatically adjust the number of entries to whatever fits in PAGE_SIZE. diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c --- a/drivers/video/fbsysfs.c +++ b/drivers/video/fbsysfs.c @@ -244,15 +244,15 @@ static ssize_t show_virtual(struct class /* Format for cmap is "%02x%c%4x%4x%4x\n" */ Why is the alpha channel not given the same weight as the RGB? Wouldn't it be correct to also give it 4 bytes (16 bits) Also, what would happen if you exceed 256 entries, you've only alloted a maximum of 256 for the index? This will also be a problem because you cannot access cmap entries past 255. So, 4 bytes per channel + 4 bytes for the index will be needed per entry, Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Jon Smirl wrote:
On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
On Thu, 28 Jul 2005, Jon Smirl wrote:
I've verified now that all ATI R300+ chips have 10bit cmaps. These are
pretty common so I'd be in favor of making this into a binary
attribute where I can get/set the whole table at once. Given that
OpenGL is already supporting 12 and 16 bits these tables are only
going to get much larger.
1024 entries * 5 fields * 2 bytes = 10KB -- too big for a text attribute.
65536 entries * 5 fields * 2 bytes = 655KB -- way too big for a text attribute.
The bits_per_pixel sysfs attribute is an easy way to tell how many
entries you need. You can just set it at 4, 8, 10, etc until you get
an error. Now you know the max. 2^n and you know how many entries.
No, bits_per_pixel can be (much) larger than the color map size. E.g. a simple
ARGB directcolor mode has bits_per_pixel = 32 and color map size = 256.
So I have the bits_per_pixel attribute wrong in sysfs. It needs to be
bits_per_color and then let the driver sort it out. Otherwise there
is no way to set ARGB versus ARGB2101010. With bits per color you
would set 8 or 10.
No, you have to add another attribute for {transp|red|green|blue}.{len,offset}
and another attribute for the pixelformat. Then using those, one can
easily deduce the cmap size.
If that isn't good enough I can switch the attribute to take strings
like ARGB.
Please no.
What do you think, should I just switch to fbconfig names and a binary
cmap attribute?
Does a binary attribute not have the same buffer size limitation as
the text attribute? I really don't know, just asking.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Geert Uytterhoeven wrote: On Thu, 28 Jul 2005, Antonino A. Daplas wrote: Jon Smirl wrote: On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: On Wed, 27 Jul 2005, Linux Kernel Mailing List wrote: There are a couple of ways to fix this. 1) Add a check to limit use of the sysfs attributes to 256 entries. If you want more you have to use /dev/fb0 and the ioctl. More is an uncommon case. 2) Switch this to a binary parameter. Now you have to use tools like hexdump instead of cat to work with the data. It was nice to be able to use cat to see the current map. Does anyone have preferences for which way to fix it? Or... 3) Add another file in sysfs which specifies at what index and how many entries will be read or written from or to the cmap. With this additional sysfs file, it should be able to handle any reasonable cmap length, but it will take more than one reading of the color_map file. Another advantage is that the entire color map need not be read or written if only one field needs to be changed. I've attached a test patch. Let me know what you think. I like it! ... But, a disadvantages is that it needs to store state between two non-atomic operations. E.g. imagine two processes doing this at the same time. We can add a check that if the incoming buffer index start and length does not match the current start and len (as set by cmap_range), then exit with and empty buffer. Conversely, users can always check if the output read from color_map matches the value it entered in cmap_range. As a side note: The rest of the fbsysfs attributes suffer from the same thing, especially since the value of each attribute depends on each other. What if one process reads the virtual_size, while another one changes the bits_per_pixel? I'm pretty sure that setting bits_per_pixel to a higher value will almost always change the virtual_size. Currently, the only way to guarantee atomicity is to use the ioctls. The main reason why we change the video mode, framebuffer format, color format, etc in one go with fb_set_var() is precisely this. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vesafb-fix-mtrr-bugs.patch added to -mm tree
Andrew Morton wrote: Dave Jones <[EMAIL PROTECTED]> wrote: On Fri, Jul 29, 2005 at 11:24:37AM -0700, Andrew Morton wrote: > From: "Antonino A. Daplas" <[EMAIL PROTECTED]> > > >> vesafb: mode is 800x600x16, linelength=1600, pages=16 > >> vesafb: scrolling: redraw > >> vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 > >> mtrr: type mismatch for fc00,100 old: write-back new: write- > >> combining > > Range is already set to write-back, vesafb attempts to add a write-combining > mtrr (default for vesafb). > > >> mtrr: size and base must be multiples of 4 kiB > > This is a bug, vesafb attempts to add a size < PAGE_SIZE triggering > the messages below. I fixed this a few weeks back. It's this line which your patch removes.. -while (temp_size > PAGE_SIZE && > To eliminate the warning messages, you can add the option mtrr:2 to add a > write-back mtrr for vesafb. Or just use nomtrr option. If we need users to pass extra command line args to make warnings go away, we may as well not bother. Because 99% of users will be completely unaware that option even exists. They'll still see the same message, and still report the same bugs. The pains of MTRR strike again. This stuff is just screaming for a usable PAT implementation. Andi, you were working on that, any news ? Or should I resurrect Terrence's patch again ? Well something is still awry: Begin forwarded message: Date: Fri, 29 Jul 2005 13:40:05 +0200 From: Alessandro <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Subject: Re: "mtrr: type mismatch for e000,800 old: write-back new: write-combining" on Kernel 2.6.12 I try the new prepatch for the stable Linux kernel (2.6.13-rc4) but the problem is the same: ... vesafb: framebuffer at 0xe000, mapped to 0xe088, using 4608k, total 131072k vesafb: mode is 1024x768x24, linelength=3072, pages=55 vesafb: protected mode interface info at c000:56cb vesafb: scrolling: redraw vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 mtrr: type mismatch for e000,800 old: write-back new: write-combining mtrr: type mismatch for e000,400 old: write-back new: write-combining mtrr: type mismatch for e000,200 old: write-back new: write-combining mtrr: type mismatch for e000,100 old: write-back new: write-combining mtrr: type mismatch for e000,80 old: write-back new: write-combining mtrr: type mismatch for e000,40 old: write-back new: write-combining mtrr: type mismatch for e000,20 old: write-back new: write-combining mtrr: type mismatch for e000,10 old: write-back new: write-combining mtrr: type mismatch for e000,8 old: write-back new: write-combining mtrr: type mismatch for e000,4 old: write-back new: write-combining mtrr: type mismatch for e000,2 old: write-back new: write-combining mtrr: type mismatch for e000,1 old: write-back new: write-combining mtrr: type mismatch for e000,8000 old: write-back new: write-combining mtrr: type mismatch for e000,4000 old: write-back new: write-combining mtrr: type mismatch for e000,2000 old: write-back new: write-combining Vesafb defaults to write-combining mtrr. But the memory range is already set to write-back so mtrr_check() spewed the above messages. I don't think it has any ill effects, but if you want to eliminate the above messages, tell vesafb to also use write-back mtrr by adding the boot option "mtrr:2" (or nomtrr). I think I'll submit a documentation patch. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Where is place of arch independed companion chips?
Andrey Volkov wrote: Hi Greg, While I write driver for SM501 CC (which have graphics controller, USB MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard), I bumped with next ambiguity: Where is a place of this chip's Kconfig/drivers in kernel config/drivers tree? May be create new node in drivers subtree? Or put it under graphics node (since it's main function of this CC)? You will have to split your driver (graphics under drivers/video, usb under drivers/usb, ac97 under sound, video capture under drivers/media, etc. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13-rc4] framebuffer: new driver for cyberblade/i1 core
Knut Petersen wrote:
Currently tridenfb claims to support the cyberblade/i1 graphics core.
This is of very limited truth. There is a great number of bugs, even
vesafb is faster and provides more working modes and much better
quality of the video signal.
Tridentfb seems to be unmaintained,and documentation for most of the
supported chips is not available. Fixing cyberblade/i1 support inside
of tridentfb was not an option, it would have caused numerous
if(CYBERBLADEi1) else ... cases and would have rendered the code
to be almost unmaintainable.
This code does support the graphics core of a single north bridge
and has been tested and developed on a system equipped with that
chip. It cannot break anything but the broken cyberblade/i1 support
of tridentfb, and even if that would be the case, there is still
vesafb as a working alternative. On the other hand it provides
significant improvements. Because of this I believe that there is
no reason to keep it out of 2.6.13 just because it is presented a
bit late in the development cycle.
Signed-off-by: Knut Petersen <[EMAIL PROTECTED]>
diff -urN linux-2.6.13-rc4/Documentation/fb/cyblafb.txt
linux-2.6.13-rc4-tfix/Documentation/fb/cyblafb.txt
--- linux-2.6.13-rc4/Documentation/fb/cyblafb.txt1970-01-01
01:00:00.0 +0100
+++ linux-2.6.13-rc4-tfix/Documentation/fb/cyblafb.txt2005-07-31
09:38:44.0 +0200
@@ -0,0 +1,354 @@
+CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core
integrated
+into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
+tested using a VIA EPIA 5000 board.
Nice docs :-)
+
config FB_TRIDENT
tristate "Trident support"
depends on FB && PCI
@@ -1193,8 +1219,12 @@
but also on some motherboards. For more information, read
+ Attention: Cyberblade/i1 support has been removed, choose the
+ cyblafb driver instead.
+
Is it really necessary to remove it from tridentfb so soon? Maybe you
can add a warning first, then remove it after a few development cycles.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION "0.50"
+
+struct cyblafb_par {
+void __iomem * io_virt; //iospace virtual memory address
+};
+
+static struct cyblafb_par default_par;
+static struct fb_info fb_info;
Do this in the beginning of cybla_pci_probe()
struct fb_info *info;
info = framebuffer_alloc(sizeof(struct cyblafb_par), dev->dev);
if (info)
exit;
Then do a corresponding framebuffer_dealloc() on exit/unload.
This way, you need not statically allocate memory for the par
and info, which increases the kernel image size unnecessarily.
And so you don't lose your info structure, do this:
pci_set_drvdata(dev, info) at the end of cybla_pci_probe()
To get your info back (ie. in cybla_pci_remove()), do this:
struct fb_info *info = pci_get_drvdata(dev);
+static struct fb_var_screeninfo default_var;
You also don't need to allocate this. default_var is used only
during init. Why not use info->var? Or if you can't, mark it
__devinitdata.
+static struct fb_fix_screeninfo cyblafb_fix = {
+.id = "CyBla",
+.type = FB_TYPE_PACKED_PIXELS,
+.ypanstep = 1,
+.visual = FB_VISUAL_PSEUDOCOLOR,
+.accel = FB_ACCEL_NONE,
+};
Same with the above. You can mark it __devinitdata and
don't reference it again after saving it in info->fix.
+
+static u32 pseudo_pal[16];
+
+static int displaytype;
+
+static char *mode = NULL;
+static int bpp = 8;
+static int ref = 75;
+static int fp;
+static int crt;
+static int nativex;
+static int center;
+static int stretch;
+static int pciwb = 1;
+static int pcirb = 1;
+static int pciwr = 1;
+static int pcirr = 1;
+static int memsize;
+static int verbosity;
+static int vesafb;
Any of the above that can be marked __devinitdata? For those
that you need after initialization, place them in info->par.
+
+module_param(mode, charp, 0);
+module_param(bpp, int, 0);
+module_param(ref, int, 0);
+module_param(fp, int, 0);
+module_param(crt, int, 0);
+module_param(nativex, int, 0);
+module_param(center, int, 0);
+module_param(stretch, int, 0);
+module_param(pciwb, int, 0);
+module_param(pcirb, int, 0);
+module_param(pciwr, int, 0);
+module_param(pcirr, int, 0);
+module_param(memsize, int, 0);
+module_param(verbosity, int, 0);
+module_param(vesafb, int, 0);
+
+
+//=
+//
+// Port access macros for memory mapped io
+//
+//=
+
+#define out8(r,v)writeb(v,((struct cyblafb_par
*)fb_info.par)->io_virt+r)
+#define out32(r,v) writel(v,((struct cyblafb_par
*)fb_info.par)->io_virt+r)
+#define in8(r) readb(((struct cyblafb_par
*)fb_info.par)->io_virt+r)
+#define in32(r) readl(((struct cyblafb_par *)fb_info.par)->io_virt+r)
If you use framebuffer_alloc(), you can change the above macros to
(struct cyblafb_par *)info->par->io_virt+r, for example.
+//=
Re: [PATCH] race condition with drivers/char/vt.c (bug in vt_ioctl.c)
There's a similar report in Kernel Bugzilla
http://bugzilla.kernel.org/show_bug.cgi?id=4812
I was wondering what's the likelihood of tty->driver_data being NULL in
vt_ioctl but never had the time to do further exploration. Your patch
should fix that bug too.
Tony
Steven Rostedt wrote:
While debugging Ingo's RT patch, I came accross this race condition.
The mainline seems to be susceptible to this bug, although it may be 1
in a 1,000,000 to happen. But those are the nastiest races.
With debugging information in the RT patch, I was able to reproduce this
race several times. Enough to be able to debug it.
The race is with the tty->driver_data, tty->count and vt.c
Here's the scoop:
Process P1 opens a tty:
tty_open
--> init_dev
sets tty->count to 1
P1 does what it needs to, and closes the tty.
tty_release (now showing locks)
(grabs BKL)
--> release_dev
--> tty->driver->close ==> con_close (vt.c)
(down tty_sem)
(aquire console_sem)
tty->driver_data = NULL
Now process P2 opens the console:
tty_open
(block on tty_sem)
back to P1
(release console_sem)
(up tty_sem)
back to P2
(down tty_sem)
--> init_dev
tty->count++ (tty->count now == 2)
(up tty_sem)
--> tty->driver->open ==> con_open (vt.c)
(aquire console_sem)
if (tty->count == 1) (which it does not)
allocate tty->driver_data
(which doesn't happen)
(release console_sem)
And P2 goes happily along with driver_data == NULL.
Now in something like vt_ioctl (which I first saw the bug)
int vt_ioctl(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg)
{
struct vc_data *vc = (struct vc_data *)tty->driver_data;
struct console_font_op op; /* used in multiple places here */
struct kbd_struct * kbd;
unsigned int console;
unsigned char ucval;
void __user *up = (void __user *)arg;
int i, perm;
console = vc->vc_num;
Where here vc->vc_num could very well be (0)->vc_num.
I googled a little and found where this may have already happened in the
main line kernel:
http://seclists.org/lists/linux-kernel/2005/Aug/1603.html
So here's my proposal:
Instead of checking for tty->count == 1 in con_open, which we see is
not reliable. Just check for tty->driver_data == NULL.
This should work since it should always be NULL when we need to assign
it. If we switch the events of the race, so that the init_dev went
first, the driver_data would not be NULL and would not need to be
allocated, because after init_dev tty->count would be greater than 1
(this is assuming the case that it is already allocated) and the
con_close would not deallocate it. The tty_sem and console_sem and
order of events protect the tty->driver_data but not the tty->count.
Without the patch, I was able to get the system to BUG on bootup every
other time. With the patch applied, I was able to bootup 6 out of 6
times without a single crash.
-- Steve
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6-git10/drivers/char/vt.c.orig 2005-08-19
22:51:25.0 -0400
+++ linux-2.6.13-rc6-git10/drivers/char/vt.c2005-08-19 22:52:22.0
-0400
@@ -2433,7 +2433,7 @@ static int con_open(struct tty_struct *t
int ret = 0;
acquire_console_sem();
- if (tty->count == 1) {
+ if (tty->driver_data == NULL) {
ret = vc_allocate(currcons);
if (ret == 0) {
struct vc_data *vc = vc_cons[currcons].d;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info->flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/intelfb/intelfbdrv.c
b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -502,7 +502,7 @@ intelfb_pci_register(struct pci_dev *pde
struct agp_bridge_data *bridge;
int aperture_bar = 0;
int mmio_bar = 1;
- int offset;
+ int offset, remap;
DBG_MSG("intelfb_pci_register\n");
@@ -662,11 +662,15 @@ intelfb_pci_register(struct pci_dev *pde
+ (dinfo->cursor.size >> 12);
}
+ if (dinfo->fbmem_gart)
+ remap = (dinfo->fb.offset << 12) + dinfo->fb.size;
+ else
+ remap = (dinfo->cursor.offset << 12) + dinfo->cursor.size;
+
/* Map the fb and MMIO regions */
/* ioremap only up to the end of used aperture */
dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo->aperture.physical, (dinfo->fb.offset << 12)
-+ dinfo->fb.size);
+ (dinfo->aperture.physical, remap);
if (!dinfo->aperture.virtual) {
ERR_MSG("Cannot remap FB region.\n");
cleanup(dinfo);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Sebastian Kaergel wrote:
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.
Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.
CC'ed Sylvain.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0
Can you try the patch anyway?
If the patch does not fix your problem, can you revert the patches and
see which is the culprit. I'm attaching those 2 patches.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drivers/video/intelfb/intelfbdrv.c: needs update
Index: drivers/video/intelfb/intelfbdrv.c
===
--- 0582536f492dc10e4849053d19fec93ca72e9bfe/drivers/video/intelfb/intelfbdrv.c
(mode:100644)
+++ uncommitted/drivers/video/intelfb/intelfbdrv.c (mode:100644)
@@ -579,23 +579,6 @@
return -ENODEV;
}
- /* Map the fb and MMIO regions */
- dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo->aperture.physical, dinfo->aperture.size);
- if (!dinfo->aperture.virtual) {
- ERR_MSG("Cannot remap FB region.\n");
- cleanup(dinfo);
- return -ENODEV;
- }
- dinfo->mmio_base =
- (u8 __iomem *)ioremap_nocache(dinfo->mmio_base_phys,
- INTEL_REG_SIZE);
- if (!dinfo->mmio_base) {
- ERR_MSG("Cannot remap MMIO region.\n");
- cleanup(dinfo);
- return -ENODEV;
- }
-
/* Get the chipset info. */
dinfo->pci_chipset = pdev->device;
@@ -679,6 +662,26 @@
}
/* Allocate memories (which aren't stolen) */
+ /* Map the fb and MMIO regions */
+ /* ioremap only up to the end of used aperture */
+ dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
+ (dinfo->aperture.physical, ((offset + dinfo->fb.offset) << 12)
++ dinfo->fb.size);
+ if (!dinfo->aperture.virtual) {
+ ERR_MSG("Cannot remap FB region.\n");
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
+ dinfo->mmio_base =
+ (u8 __iomem *)ioremap_nocache(dinfo->mmio_base_phys,
+ INTEL_REG_SIZE);
+ if (!dinfo->mmio_base) {
+ ERR_MSG("Cannot remap MMIO region.\n");
+ cleanup(dinfo);
+ return -ENODEV;
+ }
+
if (dinfo->accel) {
if (!(dinfo->gtt_ring_mem =
agp_allocate_memory(bridge, dinfo->ring.size >> 12,
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -643,8 +643,8 @@ fb_pan_display(struct fb_info *info, str
int
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
{
- int err;
-
+ int err, flags = info->flags;
+
if (var->activate & FB_ACTIVATE_INV_MODE) {
struct fb_videomode mode1, mode2;
int ret = 0;
@@ -697,7 +697,7 @@ fb_set_var(struct fb_info *info, struct
!list_empty(&info->modelist))
err = fb_add_videomode(&mode, &info->modelist);
- if (!err && info->flags & FBINFO_MISC_USEREVENT) {
+ if (!err && flags & FBINFO_MISC_USEREVENT) {
struct fb_event event;
int evnt = (var->activate & FB_ACTIVATE_ALL) ?
FB_EVENT_MODE_CHANGE_ALL :
Re: Linux-2.6.13-rc7
Sorry. Here's the start of the thread. Tony On Tue, 23 Aug 2005 22:08:13 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Antonino A. Daplas: > intelfb/fbdev: Save info->flags in a local variable > Sylvain Meyer: > intelfb: Do not ioremap entire graphics aperture One of these changes broke intelfb. The same .config from 2.6.13-rc6 does no longer work for -rc7. After booting the screen stays black, but i can type blindly. I can also start X. dmesg does not show anything unusual. any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove race between con_open and con_close
Paul Mackerras wrote:
I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.
What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data. Then process A closes that and concurrently process
B opens /dev/tty6. Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1. However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).
So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data. Then when the
process tries to do anything with that fd, it oopses.
The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open. The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem. We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called. Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Could this go into 2.6.13 please?
I agree this should go to 2.6.13. Though you've been beaten to the punch
by Steven Rostedt. This is already in the mm tree.
http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2
Tony
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.6/drivers/char/vt.c pmac-2.6/drivers/char/vt.c
--- linux-2.6/drivers/char/vt.c 2005-07-17 10:59:52.0 +1000
+++ pmac-2.6/drivers/char/vt.c 2005-08-27 22:59:36.0 +1000
@@ -2433,7 +2433,7 @@
int ret = 0;
acquire_console_sem();
- if (tty->count == 1) {
+ if (tty->driver_data == NULL) {
ret = vc_allocate(currcons);
if (ret == 0) {
struct vc_data *vc = vc_cons[currcons].d;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13
Nigel Cunningham wrote: Hi. On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote: On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote: Paul Mackerras: Remove race between con_open and con_close Hey, I'm the first to report this with the fix and Paul gets the credit? I guess I'll crawl back to my little world (RT) where they actually appreciate me. :-( Did you report it or fix it? :> Both, actually, with exactly the same patch. In the long changelog, both Steven and Paul are co-signees but only Paul's name appeared in the short changelog. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts
Knut Petersen wrote: > fb_pad_aligned_buffer() is also slower for those cases. But does anybody > use such fonts? Yes, there are 16x30 fonts out there in the wild. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts
Knut Petersen wrote: > This trivial patch gives a performance boost to the framebuffer console > > Constructing the bitmaps that are given to the bitblit functions of the > framebuffer > drivers is time consuming. Here we avoide a call to the slow > fb_pad_aligned_buffer(). > The patch replaces that call with a simple but much more efficient > bytewise copy. > > The kernel spends a significant time at this place if you use 8x* fonts. > Every > pixel displayed on your screen is prepared here. > > Some benchmark results: > > Displaying a file of 2000 lines with 160 characters each takes 889 ms > system > time using cyblafb on my system (I´m using a 1280x1024 video mode, > resulting in a 160x64 character console) > > Displaying the same file with the enclosed patch applied to 2.6.13 only > takes > 760 ms system time, saving 129 ms or 14.5%. Where did this 14.5% come from? Is it bit_putcs alone or is more real world, such as 'time cat text_file'? If I'm to guess, a large percent of the improvement is caused by the inlining of the code. I'm not against the patch, it will benefit drivers with very fast imageblits. However, since most drivers have imageblits done in software, a large proportion of the processing time will go to the imageblit itself, so I don't think you'll get that high a number (I get only a 4% improvement, and this is in a driver with accelerated blits, and it will probably be lower, ie, in vesafb). Anyway, with the addition of your patch, bit_putcs has now reached an 'ugliness threshhold' for a revamp. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts
Roman Zippel wrote: > Hi, > > On Wed, 31 Aug 2005, Knut Petersen wrote: > >> How could I make it an inline function? It is used in console/bitblit.c, >> nvidia/nvidia.c, >> riva/fbdev.c and softcursor.c. > > Something like below, which has the advantange that there is still only > one implementation of the function and if it's still slower, we really > need to check the compiler. > I do get better numbers with this, not much, but better than Knut's (5ms), and definitely much better than the old uninlined one (100ms). Andrew, don't get this yet. I'll incorporate this with the bit_putcs() breakup that I'm currently doing. Roman, okay if you have a 'Signed-off-by' line? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty problem
Nilesh Agrawal wrote: > Hi all, > > I have a peculiar problem with the kernel messages being printed during > startup. > During startup the messages are printed only uptill the monitor > (screen) gets filled, the screen doesnt scroll down and no further > messages are printed. However the computer boots normally, and I get my > graphical desktop when X starts. > Moreover moving to tty1 (CTRL-ALT-F1) doesnt give me anything, but > mingetty program is running on tty1. > Booting in single user mode, the same problem persists. I cant see > anything after the screen gets filled. > Does anyone know where is the problem?? > Thanks in advance. Please send more info --- output of dmesg, kernel config, hardware desription. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: who sets boot_params[].screen_info.orig_video_isVGA?
[EMAIL PROTECTED] wrote:
> Thanks for the reply, Matthew.
>
> On Mon, 5 Sep 2005, Matthew Garrett wrote:
>
>> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> I am trying to get intelfb running on a system with a 855GM onboard
>>> chip,
>>> and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13,
>>> line
>>> 814:
>>>
>>> if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
>>> ERR_MSG("Video mode must be programmed at boot time.\n");
>>> cleanup(dinfo);
>>> return -ENODEV;
>>> }
>>
>> This ought to be done by the bootloader if you pass a vga=foo argument.
>> The framebuffer driver doesn't know how to switch resolutions (primarily
>> because Intel won't tell anyone how to do it, so the only method is a
>> real-mode BIOS call to the VESA BIOS)
>
> Do I get it right, that, say, if I tell grub to load a kernel and
> specify "vga=xxx" on the kernel command line, grub will interpret it,
> issue some VESA BIOS calls and fill in the screen_info struct? If so,
> the card often supports several modes (VGA, SVGA, VESA, different
> resolutions, colour depths, etc.), right? So, which one will be chosen?
> Does it depend on the specific value I give to "vga="? How do I force
> VIDEO_TYPE_VLFB (VESA VGA in graphic mode) mopde then?
>
> BTW, I didn't find any code in grub that sets up screen_info, or it's
> very well hidden:-)
One good method is to use the "vesa" driver of Xorg/Xfree86. Check
/var/log/X*.log and it should have a nice list of vesa mode id's that
are supported.
Then add 0x200 to any of them and use it in your vga= parameter.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: who sets boot_params[].screen_info.orig_video_isVGA?
[EMAIL PROTECTED] wrote: > On Mon, 5 Sep 2005, Matthew Garrett wrote: > >> Yup. You probably want to take a look at Documentation/fb/vesafb.txt - >> the modes are the same. > > Great, thanks! I tried VESA 0x111 (Linux 0x311) - it is also what is > used by xfree86 vesa driver, after I've followed the suggestion from > Tony (cc'ed and quoted below) and tried X with vesa. The kernel boots, > intelfb driver doesn't exit, I can even start X over fb and it runs! But: > > 1) both screens - LCD and CRT bocome black as soon as intelfb takes over > and stay that way also under X > > 2) kernel logs fill with > > intelfb: the cursor was killed - restore it !! > intelfb: size 8, 16 pos 0, 464 > > Buggy video BIOS?... There might be a bug with the ioremap patch that got in by the time linux-2.6.13 was released. The intelfb maintainer is still working on it. You can try to revert that patch (just make sure that the graphics aperture in the BIOS is set to <= 128MB) or use vesafb for now. Here's the link to that patch: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=6bd49341f2806168c877e12cefca77b93437bac2;hp=89204c40a03346cd951e698d854105db4cfedc28 Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fbdev status (was Re: kernel status, 5 Sep 2005)
Andrew Morton wrote: > > [Bugme-new] [Bug 5059] New: intelfb - do not keep console resolution > http://bugzilla.kernel.org/show_bug.cgi?id=5059 Fixed in 2.6.13 > > [Bugme-new] [Bug 5130] New: atyfb driver kernel panic on boot on > http://bugzilla.kernel.org/show_bug.cgi?id=5130 Not really a bug, more of a misconfigured kernel. This bug is closed. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: > (resend due to mailer issues. Apologies to anyone receiving this twice) > > This patch series reworks the Xilinx framebuffer driver and then adds > an of_platform bus binding. The of_platform bus binding is needed to use > the driver in arch/powerpc platforms. > > Antonino, > > Assuming there are no major issues, I'd like to get this patch series > queued up for inclusion in 2.6.24. Okay. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Sat, 2007-10-06 at 22:09 +0200, Jan Engelhardt wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
>
> References: http://lkml.org/lkml/2007/4/1/162
> http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
>
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
>
> ---
> drivers/char/Kconfig | 42 ++
> drivers/char/vt.c| 23 +++
> 2 files changed, 65 insertions(+)
>
> Index: linux-2.6.23/drivers/char/Kconfig
> ===
> --- linux-2.6.23.orig/drivers/char/Kconfig
> +++ linux-2.6.23/drivers/char/Kconfig
> @@ -58,6 +58,48 @@ config VT_CONSOLE
>
> If unsure, say Y.
>
> +config VT_CKO
> + bool "Colored kernel message output"
> + depends on VT_CONSOLE
> + ---help---
> + This option enables kernel messages to be emitted in
> + colors other than the default.
> +
> + If unsure, say N.
> +
> +config VT_PRINTK_COLOR
> + hex "Colored kernel message output"
> + range 0x00 0xFF
> + depends on VT_CKO
> + default 0x07
> + ---help---
> + This option defines with which color kernel messages will be
> + printed to the console.
> +
> + The value you need to enter here is the value is composed
The more correct term for "The value" is probably "The attribute".
> + (OR-ed) of a foreground and a background color.
> +
> + Foreground:
> + 0x00 = black, 0x08 = dark gray,
> + 0x01 = red, 0x09 = light red,
> + 0x02 = green, 0x0A = light green,
> + 0x03 = brown, 0x0B = yellow,
> + 0x04 = blue,0x0C = light blue,
> + 0x05 = magenta, 0x0D = light magenta,
> + 0x06 = cyan,0x0E = light cyan,
> + 0x07 = gray,0x0F = white,
> +
> + (Foreground colors 0x08 to 0x0F do not work when a VGA
> + console font with 512 glyphs is used.)
You might have to include a warning that those values or attributes are
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.
For 2-colors (we still have quite a few of them) only bit 0 is true for
color (0x00 and 0x01). The rest of the bits are interpreted as
attributes:
0x02 - italic
0x04 - underline
0x08 - bold
0x80 - blink
The italic, underline and bold attributes will show up in a 2-color
framebuffer console. The blink attribute is ignored.
With a 4-color fb console (4-level grayscale), those values are again
interpreted differently.
0x00 - 0x00 : black
0x01 - 0x06 : white
0x07 - 0x08 : gray
the rest: intense white
(If by mistake 0x0106 is used, it will produce a white on white display)
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:
With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.
And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.
> +
> + Background:
> + 0x00 = black, 0x40 = blue,
> + 0x10 = red, 0x50 = magenta,
> + 0x20 = green, 0x60 = cyan,
> + 0x30 = brown, 0x70 = gray,
> +
> + For example, 0x1F would yield white on red.
> +
You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.
> config HW_CONSOLE
> bool
> depends on VT && !S390 && !UML
> Index: linux-2.6.23/drivers/char/vt.c
> ===
> --- linux-2.6.23.orig/drivers/char/vt.c
> +++ linux-2.6.23/drivers/char/vt.c
> @@ -73,6 +73,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
>
> #ifdef CONFIG_VT_CONSOLE
>
> +static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
> +#ifdef CONFIG_VT_CKO
> +module_param(printk_color, uint, S_IRUGO | S_IWUSR);
> +
> +static inline void vc_set_color(struct vc_data *vc, unsigned char color)
> +{
> + vc->vc_color = color_table[color & 0xF] |
> +(color_table[(color >> 4) & 0x7] << 4) |
> +(color & 0x80);
You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Tue, 2007-10-09 at 01:31 +0200, Jan Engelhardt wrote: > On Oct 9 2007 07:12, Antonino A. Daplas wrote: > >> > >> References: http://lkml.org/lkml/2007/4/1/162 > >>http://lkml.org/lkml/2007/10/5/199 > > > >This is quite a long thread :-) > > It was a patch series after all. But as Greg puts it, be persistent. > > >> +config VT_PRINTK_COLOR > >> + hex "Colored kernel message output" > >> + range 0x00 0xFF > >> + depends on VT_CKO > >> + default 0x07 > >> + ---help--- > >> + This option defines with which color kernel messages will be > >> + printed to the console. > >> + > >> + The value you need to enter here is the value is composed > > > >The more correct term for "The value" is probably "The attribute". > > "The value for this kconfig entry" it should read in the minds. > > >> + (Foreground colors 0x08 to 0x0F do not work when a VGA > >> + console font with 512 glyphs is used.) > > > >You might have to include a warning that those values or attributes are > >interpreted differently depending on the driver used, and the above is > >mostly true for 16-color console drivers only. > > Are there any other drivers besides vgacon and fbcon that use vt.c? All drivers under drivers/video/console. That would be: vgacon dummycon fbcon newport_con sticon promcon mdacon There are perhaps a few more drivers outside this directory, such as sisusbcon or something. > >You may want to leave out the blink attribute (0x80) from this part. > >Otherwise setterm -blink on|off will produce the opposite effect. > > But 0x80 might be interpreted in a different fashion for some othercon, > yielding for example superbold rather than blinking. That's right. But setting the blink attribute is done with an XOR (^). So 'setterm -blink' on will unset the blink attribute (0x80 ^ 0x80). > I'll have to try this, because usually, setterm operates on TTYs > rather than VCs. Yes, but if the tty driver type is a virtual console, then vt.c is still affected. Well the blink attribute is ignored by most drivers, if I'm not mistaken. So you generally won't see the effect :-). But with fbcon, the blink attribute is interpreted as "change background color from black to light gray". Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleepy linux 2.6.23-rc9
On Tue, 2007-10-09 at 00:05 +0200, Pavel Machek wrote: > Hi! > > I played with powertop a bit, and found a fairly interesting failure > mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice. > > When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups > are caused by cursor painting (I should fix that some day, I > guess). But... the cursor blinking does not even work properly! > > It blinks at normal speed, then (randomly) it blinks slowly, then gets > back to normal speed, then inserts longer delay. > > The effect is so nice that I thought about youtube ;-). Thinkpad > x60.. question is, how to debug it? The cursor blinking is done by software via a timer. It's in drivers/video/console/fbcon.c. With the latest -rc kernel you can turn off the blinking with echo 0 > /sys/class/graphics/fbcon/cursor_blink Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: > On 10/2/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: > > > Assuming there are no major issues, I'd like to get this patch series > > > queued up for inclusion in 2.6.24. > > > > Okay. > > > > Tony > > BTW, what path do framebuffer patches take to get into Linus' tree? > Does he pull your tree directly, or do they go through someone else's > tree? They all go to -mm tree, unless it's a needed fix, then to Linus's. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote: > On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: > > > BTW, what path do framebuffer patches take to get into Linus' tree? > > > Does he pull your tree directly, or do they go through someone else's > > > tree? > > > > They all go to -mm tree, unless it's a needed fix, then to Linus's. > > > > Tony > > Ah, okay. > > Since the XilinxFB is a powerpc-only device, is it okay with you if I > get Paul Mackerras to merge them into his tree instead (that way the > changes go in with the platform code which requires these changes) Fine with me. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] kill include/video/edid.h
On Monday 21 March 2005 03:29, Adrian Bunk wrote: > This patch removes some completely unused code. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > > arch/i386/boot/compressed/misc.c |1 - > arch/i386/kernel/setup.c |4 > arch/x86_64/kernel/setup.c |3 --- > drivers/video/fbmon.c|1 - > drivers/video/vesafb.c |3 --- > include/asm-i386/setup.h |1 - > include/asm-x86_64/bootsetup.h |1 - > include/video/edid.h | 27 --- > 8 files changed, 41 deletions(-) > > --- linux-2.6.11-mm4-full/arch/i386/kernel/setup.c.old2005-03-20 > 20:06:06.0 +0100 +++ > linux-2.6.11-mm4-full/arch/i386/kernel/setup.c2005-03-20 > 20:06:45.0 +0100 @@ -43,8 +43,6 @@ > #include > #include > > -#include > - > #include > #include > #include > @@ -118,7 +116,6 @@ > unsigned short length; > unsigned char table[0]; > }; > -struct edid_info edid_info; > struct ist_info ist_info; > struct e820map e820; > > @@ -1468,7 +1465,6 @@ > ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV); > drive_info = DRIVE_INFO; > screen_info = SCREEN_INFO; > - edid_info = EDID_INFO; > apm_info.bios = APM_BIOS_INFO; > ist_info = IST_INFO; > saved_videomode = VIDEO_MODE; > --- linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c.old 2005-03-20 > 20:04:42.0 +0100 +++ > linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c 2005-03-20 > 20:07:11.0 +0100 @@ -48,7 +48,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -100,7 +99,6 @@ > unsigned char table[0]; > }; > > -struct edid_info edid_info; > struct e820map e820; > > extern int root_mountflags; > @@ -523,7 +521,6 @@ > ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV); > drive_info = DRIVE_INFO; > screen_info = SCREEN_INFO; > - edid_info = EDID_INFO; > saved_video_mode = SAVED_VIDEO_MODE; > bootloader_type = LOADER_TYPE; > > --- linux-2.6.11-mm4-full/drivers/video/fbmon.c.old 2005-03-20 > 20:03:56.0 +0100 +++ > linux-2.6.11-mm4-full/drivers/video/fbmon.c 2005-03-20 20:04:27.0 > +0100 @@ -34,7 +34,6 @@ > #include > #include > #endif > -#include > #include "edid.h" > > /* > --- linux-2.6.11-mm4-full/drivers/video/vesafb.c.old 2005-03-20 > 20:04:12.0 +0100 +++ > linux-2.6.11-mm4-full/drivers/video/vesafb.c 2005-03-20 20:04:18.0 > +0100 @@ -19,9 +19,6 @@ > #include > #include > #include > -#ifdef __i386__ > -#include > -#endif > #include > #include > > --- linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c.old > 2005-03-20 > 20:05:55.0 +0100 +++ > linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c2005-03-20 > 20:05:58.0 +0100 @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > #include > #include > > --- linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h.old 2005-03-20 > 20:07:33.0 +0100 +++ > linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h 2005-03-20 > 20:07:44.0 +0100 @@ -25,7 +25,6 @@ > #define KERNEL_START (*(unsigned int *) (PARAM+0x214)) > #define INITRD_START (*(unsigned int *) (PARAM+0x218)) > #define INITRD_SIZE (*(unsigned int *) (PARAM+0x21c)) > -#define EDID_INFO (*(struct edid_info *) (PARAM+0x140)) > #define EDD_NR (*(unsigned char *) (PARAM+EDDNR)) > #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF)) > #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF)) > --- linux-2.6.11-mm4-full/include/asm-i386/setup.h.old2005-03-20 > 20:07:52.0 +0100 +++ > linux-2.6.11-mm4-full/include/asm-i386/setup.h2005-03-20 > 20:07:55.0 +0100 @@ -55,7 +55,6 @@ > #define KERNEL_START (*(unsigned long *) (PARAM+0x214)) > #define INITRD_START (*(unsigned long *) (PARAM+0x218)) > #define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c)) > -#define EDID_INFO (*(struct edid_info *) (PARAM+0x140)) > #define EDD_NR (*(unsigned char *) (PARAM+EDDNR)) > #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF)) > #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF)) Not this one. Code that grabs the EDID block using the video BIOS is in video.S. Currently, there's no driver that uses this but it's an acceptable backup for drivers that want the EDID block but has no i2c, or i2c probing fails. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/
On Sunday 20 March 2005 06:59, Jesper Juhl wrote: > Checking a pointer for NULL before calling kfree() on it is redundant, > kfree() deals with NULL pointers just fine. > This patch removes such checks from files in drivers/video/ > > Since this is a fairly trivial change (and the same change made > everywhere) I've just made a single patch for all the files and CC all > authors/maintainers of those files I could find for comments. If spliting > this into one patch pr file is prefered, then I can easily do that as > well. > [snip] > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16 > 15:45:26.0 +0100 +++ > linux-2.6.11-mm4/drivers/video/console/bitblit.c 2005-03-19 > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void bit_putcs(struct > vc_data *vc > count -= cnt; > } > > - if (buf) > - kfree(buf); > + kfree(buf); > } > This is performance critical, so I would like the check to remain. A comment may be added in this section. > static void bit_clear_margins(struct vc_data *vc, struct fb_info *info, > @@ -273,8 +272,7 @@ static void bit_cursor(struct vc_data *v > dst = kmalloc(w * vc->vc_font.height, GFP_ATOMIC); > if (!dst) > return; > - if (ops->cursor_data) > - kfree(ops->cursor_data); > + kfree(ops->cursor_data); > ops->cursor_data = dst; > update_attr(dst, src, attribute, vc); > src = dst; > @@ -321,8 +319,7 @@ static void bit_cursor(struct vc_data *v > if (!mask) > return; > > - if (ops->cursor_state.mask) > - kfree(ops->cursor_state.mask); > + kfree(ops->cursor_state.mask); > ops->cursor_state.mask = mask; Although these are also performance critical, I will agree that the checks can go. Very rarely will ops->cursor_state.mask and ops->cursor_data be NULL. As for the rest, they are acceptable, as long as the maintainers agree. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/
On Monday 21 March 2005 06:02, Jesper Juhl wrote: > On Mon, 21 Mar 2005, Antonino A. Daplas wrote: > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote: > > > Checking a pointer for NULL before calling kfree() on it is redundant, > > > kfree() deals with NULL pointers just fine. > > > This patch removes such checks from files in drivers/video/ > > > > > > Since this is a fairly trivial change (and the same change made > > > everywhere) I've just made a single patch for all the files and CC all > > > authors/maintainers of those files I could find for comments. If > > > spliting this into one patch pr file is prefered, then I can easily do > > > that as well. > > > > [snip] > > > > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16 > > > 15:45:26.0 +0100 +++ > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c 2005-03-19 > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void > > > bit_putcs(struct vc_data *vc > > > count -= cnt; > > > } > > > > > > - if (buf) > > > - kfree(buf); > > > + kfree(buf); > > > } > > > > This is performance critical, so I would like the check to remain. A > > comment may be added in this section. > > Ok, I believe Andrew already merged the patch into -mm, if you really want > that check back then I'll send him a patch to put it back and add a > comment once he puts out the next -mm. > But, at the risk of exposing my ignorance, I have to ask if it wouldn't > actually perform better /without/ the if(buf) bit? The reason I say that > is that the generated code shrinks quite a bit when it's removed, and also > kfree() itself does the same NULL check as the very first thing, so it > comes down to the bennefit of shorter generated code, one less branch, > against the overhead of a function call - and how often will 'buf' be > NULL? if buff is != NULL the majority of the time, then it should be a > gain to remove the if(). You said it, buf is almost always NULL, except when the driver is in monochrome mode. So a kfree is rarely done. Anyway, if the patch is already in the tree, let's leave it at that. I would surmise that the performance loss is negligible. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/
On Monday 21 March 2005 05:49, Geert Uytterhoeven wrote: > On Mon, 21 Mar 2005, Antonino A. Daplas wrote: > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote: > > > Checking a pointer for NULL before calling kfree() on it is redundant, > > > kfree() deals with NULL pointers just fine. > > > This patch removes such checks from files in drivers/video/ > > > > > > Since this is a fairly trivial change (and the same change made > > > everywhere) I've just made a single patch for all the files and CC all > > > authors/maintainers of those files I could find for comments. If > > > spliting this into one patch pr file is prefered, then I can easily do > > > that as well. > > > > [snip] > > > > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16 > > > 15:45:26.0 +0100 +++ > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c 2005-03-19 > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void > > > bit_putcs(struct vc_data *vc > > > count -= cnt; > > > } > > > > > > - if (buf) > > > - kfree(buf); > > > + kfree(buf); > > > } > > > > This is performance critical, so I would like the check to remain. A > > comment may be added in this section. > > The first thing kfree() does is check for the NULL pointer. And since > kfree() is used a lot, it's probably already in the cache. It's not the kfree that matters, but the fact that buf is almost always NULL. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [new patch] Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/w100fb.c and add if()+comment back in drivers/video/console/bitblit.c
On Monday 21 March 2005 06:45, Jesper Juhl wrote: > On Sun, 20 Mar 2005, Jesper Juhl wrote: > > On Mon, 21 Mar 2005, Antonino A. Daplas wrote: > > > On Monday 21 March 2005 06:02, Jesper Juhl wrote: > > > > On Mon, 21 Mar 2005, Antonino A. Daplas wrote: > > > > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote: > > > > > > Checking a pointer for NULL before calling kfree() on it is > > > > > > redundant, kfree() deals with NULL pointers just fine. > > > > > > This patch removes such checks from files in drivers/video/ > > > > > > > > > > [snip] > > > > > > > > > > > --- > > > > > > linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c > > > > > > 2005-03-16 > > > > > > 15:45:26.0 +0100 +++ > > > > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19 > > > > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void > > > > > > bit_putcs(struct vc_data *vc > > > > > > count -= cnt; > > > > > > } > > > > > > > > > > > > - if (buf) > > > > > > - kfree(buf); > > > > > > + kfree(buf); > > > > > > } > > > > > > > > > > This is performance critical, so I would like the check to remain. > > > > > A comment may be added in this section. > > > > > > > > Ok, I believe Andrew already merged the patch into -mm, if you really > > > > want that check back then I'll send him a patch to put it back and > > > > add a comment once he puts out the next -mm. > > > > But, at the risk of exposing my ignorance, I have to ask if it > > > > wouldn't actually perform better /without/ the if(buf) bit? The > > > > reason I say that is that the generated code shrinks quite a bit when > > > > it's removed, and also kfree() itself does the same NULL check as the > > > > very first thing, so it comes down to the bennefit of shorter > > > > generated code, one less branch, against the overhead of a function > > > > call - and how often will 'buf' be NULL? if buff is != NULL the > > > > majority of the time, then it should be a gain to remove the if(). > > > > > > You said it, buf is almost always NULL, except when the driver is in > > > monochrome mode. So a kfree is rarely done. > > > > I see, then my change in this exact spot woul probably be a loss in the > > general case. Thank you for explaining. > > > > > Anyway, if the patch is already in the tree, let's leave it at that. I > > > would surmise that the performance loss is negligible. > > > > Well, I just spotted two cases I missed in drivers/video/ , so when I > > send that patch I might as well include a hunk that puts this one check > > back including a comment as to why it should stay. > > One case turned out not to be one when I took a closer look, so I actually > only missed one. Here's a patch to fix that last one and also put the > check in bitblit.c back. > (Andrew: this should apply on top of what you already merged) > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > > --- linux-2.6.11-mm4/drivers/video/console/bitblit.c~ 2005-03-20 > 23:40:58.0 +0100 +++ > linux-2.6.11-mm4/drivers/video/console/bitblit.c 2005-03-20 > 23:40:58.0 +0100 @@ -199,7 +199,11 @@ static void bit_putcs(struct > vc_data *vc > count -= cnt; > } > > - kfree(buf); > + /* buf is always NULL except when in monochrome mode, so in this case > +it's a gain to check buf against NULL even though kfree() handles > +NULL pointers just fine */ > + if (buf) > + kfree(buf); > } > As Joe Perch suggested, an if (unlikely(buf)) is better. Tony --- linux-2.6.11-mm4/drivers/video/console/bitblit.c~ 2005-03-20 23:40:58.0 +0100 +++ linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-20 23:40:58.0 +0100 @@ -199,7 +199,11 @@ static void bit_putcs(struct vc_data *vc count -= cnt; } - kfree(buf); + /* buf is always NULL except when in monochrome mode, so in this case + it's a gain to check buf against NULL even though kfree() handles + NULL pointers just fine */ + if (unlikely(buf)) + kfree(buf); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [2.6.11 Permedia-2 Framebuffer] driver broken (?).
On Tuesday 22 March 2005 06:59, Andrew Morton wrote: > Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote: > > Hi > > > > Worked on 2.6.10-rc2. With 2.6.11 during boot upon switching to fb, text > > becomes orange, penguins look sick (not sharp). X starts and runs normal > > (doesn't use fb), switching to vt not possible any more. Disabling > > fb-console in kernel config fixes VTs. Reverting pm2fb.c fixes the > > problem. > > Guennadi, could you please confirm that > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. >6.12-rc1-mm1/broken-out/pm2fb-x-and-vt-switching-crash-fix.patch > > fixes this one? > Actually, he was the one that confirmed that the above patch fixes this problem. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
On Tuesday 15 February 2005 07:08, Benjamin Herrenschmidt wrote: > > Appeared ? hah... that's strange. X is known to fuck up the chip when > > quit, but I wouldn't have expected any change due to the new version of > > radeonfb. From what you describe, it looks like an offset register is > > changed by X, or the surface control. > > > > My patch did not change any of radeonfb accel code though... > > > > I'll catch up with you on IRC ... > > Ok, from our discussions, it's not related to the power management code, > and an engine reset triggered by fbset fixes it. So at this point, I can > see no change in the driver explaining it... > > We did some changes to the VT layer to force a mode setting (and thus an > engine reset) when going away from X, so I can't see why that wouldn't > work, while using fbset later on works ... this goes through the same > code path in the driver... unless we are facing a timing issue... You can also try inserting something like this before register_framebuffer() info->flags |= FBINFO_MISC_MODESWITCHLATE; to delay the call to set_par as late as possible. It's the same hack used in rivafb, but there were reports before that it does not work with a few radeon setups. Tony > > X is known to play funny tricks, like touching the engine when it's in > the background (not frontmost VT) and quit, or possibly other bad things > on console switch. Maybe I changed enough delays (speeded up) the mode > switch so that we fall into a case where X has not finished mucking up > with us... > > Can you try adding some msleep(200) or so at the beginning at > radeonfb_set_par() or radeon_write_mode() to see if that makes any > difference ? > > Some printk's in there would help to... I expect calls to > radeon_engine_init() to fix it and such a call is present in the mode > restore unless accel is disabled... > > Can you check what's happening ? > > Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: i810 BUG summary. Was Re: [SoftwareSuspend-devel] [Announce] 2.1.7 for 2.6.11-rc4
On Thursday 17 February 2005 12:39, Nigel Cunningham wrote: > Hi Michael. > > Perhaps this belongs with the framebuffer devel guys? I'll copy them > now. Antonio et al, have I called it right? Is he using a framebuffer console or vgacon? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: 2.6.11-rc5
On Saturday 26 February 2005 09:13, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote: > > modedb can not be __init because fb_find_mode() may get db == NULL. > > fb_find_mode() is called from modules. > > Ahhh, good catch ! I though that was fixed long ago, looks like I was > wrong. The 2.4 fix was for fb_find_mode to always return 640x480 if modular. There's no fix yet for 2.6 except for the patch which is already in the mm tree, which is for fb_find_mode() to always fail if driver is compiled as a module. (patch below). Both fixes will still crash if fb_find_mode() is called again, so this function is really designed to be called only once. As for the other patch that removes the __init from modedb, some of the developers might disagree. Olaf, Can you send me your EDID block? You can use read-edid. Your monitor may have a fixable EDID and can be a candidate for the broken display database. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling
On Monday 28 February 2005 04:32, Olaf Hering wrote:
> On Wed, Feb 23, Linus Torvalds wrote:
> > This time it's really supposed to be a quickie, so people who can, please
> > check it out, and we'll make the real 2.6.11 asap.
>
> Here is another one, probably not new.
> Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> even if riva_create_i2c_busses fails to register all 3 busses.
>
Thanks,
Can you try this?
Fixed error handling in rivafb-i2c.c if bus registration fails.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
rivafb-i2c.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff -Nru a/drivers/video/riva/rivafb-i2c.c b/drivers/video/riva/rivafb-i2c.c
--- a/drivers/video/riva/rivafb-i2c.c 2005-01-13 03:57:12 +08:00
+++ b/drivers/video/riva/rivafb-i2c.c 2005-02-28 08:22:06 +08:00
@@ -120,8 +120,12 @@
rc = i2c_bit_add_bus(&chan->adapter);
if (rc == 0)
dev_dbg(&chan->par->pdev->dev, "I2C bus %s registered.\n",
name);
- else
- dev_warn(&chan->par->pdev->dev, "Failed to register I2C bus
%s.\n", name);
+ else {
+ dev_warn(&chan->par->pdev->dev,
+"Failed to register I2C bus %s.\n", name);
+ chan->par = NULL;
+ }
+
return rc;
}
@@ -171,6 +175,9 @@
},
};
u8 *buf;
+
+ if (!chan->par)
+ return NULL;
buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!buf) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] RFC: disallow modular framebuffers
On Tuesday 01 March 2005 10:41, Adrian Bunk wrote: > Hi, > > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and > FB_SAVAGE_ACCEL=m are currently broken) I asked myself: > > Do modular framebuffers really make sense? > > OK, distributions like to make everything modular, but all the > framebuffer drivers I've looked at parse driver specific options in > their *_setup function only in the non-modular case. > > And most framebuffer drivers contain a module_exit function. > Is there really any case where this is both reasonable and working? Only a few drivers are capable of being unloaded with the possiblity of restoring the vga console (i810fb and rivafb), when CONFIG_FBCON = n. If CONFIG_FBCON=y, it's not possible to unload the module unless 2 drivers are loaded at the same time. One driver can be mapped to the console, so the other can be unloaded. Although not important from the user's POV, it is quite helpful when debugging/developing drivers. Currently fbcon cannot be unloaded, it will freeze the system. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: disallow modular framebuffers
On Tuesday 01 March 2005 10:41, Adrian Bunk wrote: > Hi, > > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and > FB_SAVAGE_ACCEL=m are currently broken) I asked myself: BTW, what's the problem with the above? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: disallow modular framebuffers
On Friday 04 March 2005 00:56, Adrian Bunk wrote: > On Tue, Mar 01, 2005 at 09:15:27PM +0800, Antonino A. Daplas wrote: > > On Tuesday 01 March 2005 10:41, Adrian Bunk wrote: > > > Hi, > > > > > > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and > > > FB_SAVAGE_ACCEL=m are currently broken) I asked myself: > > > > BTW, what's the problem with the above? > > #if defined(CONFIG_FB_SAVAGE_ACCEL) > > doesn't work with FB_SAVAGE_ACCEL=m, and > > #if defined(CONFIG_FB_SAVAGE_ACCEL) || > defined(CONFIG_FB_SAVAGE_ACCEL_MODULE) > > would break with FB_SAVAGE=y and FB_SAVAGE_ACCEL=m. > I see. > > Is there any reason for these being three modules? > It seems the best solution would be to make this one module composed of > up to three object files? Yes. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: disallow modular framebuffers
On Friday 04 March 2005 04:20, Adrian Bunk wrote: > On Fri, Mar 04, 2005 at 03:50:42AM +0800, Antonino A. Daplas wrote: > >... > > > > > Is there any reason for these being three modules? > > > It seems the best solution would be to make this one module composed of > > > up to three object files? > > > > Yes. > > Two possible solutions: > - rename savagefb.c and link the three files into savagefb.o > - merge the other two files into savagefb.c > > I'd slightly prefer the first choice, but I can send patches for > whichever you prefer. I also prefer the first one even if it results into a big patch because of the rename. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [2.6 patch] drivers/video/: more cleanups
On Friday 04 March 2005 19:37, Adrian Bunk wrote: > On Thu, Mar 03, 2005 at 05:44:30PM -0500, Jon Smirl wrote: > > On Thu, 3 Mar 2005 22:01:19 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > This patch contains cleanups including the following: > > > > Are you cleaning up all of that annoying trailing whitespace too? It > > is always giving me problems on diffs. > > I'm not the maintainer, and such a cleanup might break all pending > patches. > > Antonino, any opinions on such cleanups? Just whitespace cleanup, no. However, they can be piggy-backed on other patches, but only on the sections affected. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH][resend] drivers/video/kyro/fbdev.c ignoring return value of copy_*_user
On Friday 04 March 2005 22:26, Jesper Juhl wrote: > Hi, > > 2.6.11 still contain these warnings : > > drivers/video/kyro/fbdev.c:597: warning: ignoring return value of > `copy_from_user', declared with attribute warn_unused_result > drivers/video/kyro/fbdev.c:607: warning: ignoring return value of > `copy_from_user', declared with attribute warn_unused_result > drivers/video/kyro/fbdev.c:628: warning: ignoring return value of > `copy_to_user', declared with attribute warn_unused_result > drivers/video/kyro/fbdev.c:631: warning: ignoring return value of > `copy_to_user', declared with attribute warn_unused_result > drivers/video/kyro/fbdev.c:634: warning: ignoring return value of > `copy_to_user', declared with attribute warn_unused_result > > Here's a patch that has been send before but obviously didn't make it in. > re-diff'ed against 2.6.11 Your patch is already in the mm tree along with the other fbdev patches. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [2.6 patch] make savagefb one module
On Saturday 05 March 2005 09:12, Adrian Bunk wrote: > On Fri, Mar 04, 2005 at 10:17:17AM +0100, Geert Uytterhoeven wrote: > > On Fri, 4 Mar 2005, Adrian Bunk wrote: > > > This patch links all selected files under drivers/video/savagefb/ into > > > one module. > > > > > > This required a renaming of savagefb.c to savagefb_driver.c . > > > > > > As a side effect, the EXPORT_SYMBOL's in this directory are no longer > > > required. > > > > > > --- > > > > > > Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily > > > possible - I do not claim being good at picking names... > > > > savagefb_core.c? > > Antonino, what's your opinion? I'll take your patch as is. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
On Tuesday 08 March 2005 09:57, Michal Januszewski wrote: > Fbsplash - The Framebuffer Splash - is a feature that allows displaying > images in the background of consoles that use fbcon. The project is > partially descended from bootsplash. > > Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture > decompression is handled by a userspace helper which provides raw image > data to the kernel. There is also no support for things like the silent > mode and progress bars, as these are best handled by userspace programs. > If splash support is really, really, really wanted in the kernel, it's probably better to just add minimal Overlay support for the framebuffer. If overlay is added, it won't be necessary to modify fbcon and the drivers, just core fb. We can have 3 levels of support. In it's most basic form, we have the display layer (what get's shown in your monitor) plus 2 buffers in system ram, the primary layer (where the console output is written) and the overlay, the static image in raw framebuffer format. Then we replace the basic framebuffer operations (imageblit, fillrect and copyarea) with ones that will read the contents of both buffers, do basic raster ops (colorkey, alpha blend, etc) before writing to the actual display buffer. The next level is both buffers are in video ram. This will need basic driver support, at least to subdivide the framebuffer memory to display, primary, and overlay. We can use the drivers accelerated drawing functions to write to the primary layer, then use software to write the processed contents to the display layer. Finally, we can enable full hardware video overlay. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
On Friday 21 January 2005 20:33, Roman Zippel wrote: > Hi, > > On Thu, 20 Jan 2005, Matt Mackall wrote: > > On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote: > > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > Next suspects would be: > > > > > > > > +cleanup-vc-array-access.patch > > > > +remove-console_macrosh.patch > > > > +merge-vt_struct-into-vc_data.patch > > > > > > Make that: > > > > > > +cleanup-vc-array-access.patch > > > +remove-console_macrosh.patch > > > +merge-vt_struct-into-vc_data.patch > > > +vgacon-fixes-to-help-font-restauration-in-x11.patch > > > > It's something in this batch. Which is good, as I'd be a bit > > disappointed if the "vt leakage" were somehow attributable to the fb > > layer. More bisection after dinner. > > Could you try the patch below. I cleaned up the logic a little in > redraw_screen() and the code below really wants to do a update_screen(). > The old switch_screen(fg_console) behaved like update_screen(fg_console). > Probably does not matter as this particular code is never invoked during framebuffer initialization (unless one uses fbcon=map:n option). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
On Friday 21 January 2005 11:57, Matt Mackall wrote: > On Thu, Jan 20, 2005 at 04:01:23PM -0800, Andrew Morton wrote: > > Matt Mackall <[EMAIL PROTECTED]> wrote: > If I do a reboot(8) from inside X, I get switched to vt 0, but the > shutdown messages come out on vt 7, where X was running. As I'm > sitting on vt 0 during shutdown, I see character cells changed to > something like "_" (last two scanlines filled) slowly marching down > the screen corresponding to the shutdown messages. Confirmed that this also occurs with vesafb. This corruption (underscores) is due to the cursor of a not visibile console being drawn on the foreground display. The console layer should decide when and where to draw the console but, for now, a simple workaround is to disallow drawing of the fbcon cursor if the console is not visible. Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]> --- fbcon.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c --- a/drivers/video/console/fbcon.c 2005-01-21 20:15:20 +08:00 +++ b/drivers/video/console/fbcon.c 2005-01-22 00:31:30 +08:00 @@ -1087,7 +1087,7 @@ int y = real_y(p, vc->vc_y); int c = scr_readw((u16 *) vc->vc_pos); - if (fbcon_is_inactive(vc, info)) + if (fbcon_is_inactive(vc, info) || !CON_IS_VISIBLE(vc)) return; ops->cursor_flash = 1; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: > Fix following section mismatch warning: > WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to > .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta') > > Browsing the code it seems that vgacon_scrollback_startup() is only > called during the init phase so the reference to the .init.text > section is OK. > Teach modpost not to warn using ___init_refok. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Acked-by: Antonino Daplas <[EMAIL PROTECTED]> Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Sun, 2007-07-22 at 12:20 +0200, Geert Uytterhoeven wrote: > On Sat, 21 Jul 2007, Antonino A. Daplas wrote: > > On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: > > > Fix following section mismatch warning: > > > WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to > > > .init.text:__alloc_bootmem (between 'vgacon_startup' and > > > 'vgacon_scrolldelta') > > > > > > Browsing the code it seems that vgacon_scrollback_startup() is only > > > called during the init phase so the reference to the .init.text > > > section is OK. > > > Teach modpost not to warn using ___init_refok. > > > > > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > > Acked-by: Antonino Daplas <[EMAIL PROTECTED]> > > I assume the check for `vga_init_done' in vgacon_startup() is sufficient to > prevent vgacon_scrollback_startup() from being called later due to > (un)bind_con_driver()? > Yes. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > Hi, > > I got this warning on current git: > > ... > > drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > used > > ... > > Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> Acked-by: Antonino Daplas <[EMAIL PROTECTED]> Thanks. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote: > I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17 > - when the code is executed it appears to lock the Dreamcast up. > > The problem seems to be: > > fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event); > > In drivers/video/fbmem.c > > This hasn't been an issue before, so are there any recent changes that > might have caused this? What's the last kernel that worked for you? Can you also post your config? > > (fb_notifier_call_chain calls a succession of stubs ending in > __blocking_notifier_call_chain in kernel/sys.c) > Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > Hi, > > I got this warning on current git: > > ... > > drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > used > > ... > > Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> > > --- > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index decfdc8..60a14de 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; > static int fbcon_is_default = 1; > static int fbcon_has_exited; > static int primary_device = -1; > +#ifndef MODULE Disrecard my other comment. This should be #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY > static int map_override; > +#endif > > /* font data */ > static char fontname[40]; Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Mon, 2007-07-23 at 14:07 +0200, Gabriel C wrote: > Antonino A. Daplas wrote: > > On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > >> Hi, > >> > >> I got this warning on current git: > >> > >> ... > >> > >> drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > >> used > >> > >> ... > >> > >> Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> > >> > >> --- > >> > >> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > >> index decfdc8..60a14de 100644 > >> --- a/drivers/video/console/fbcon.c > >> +++ b/drivers/video/console/fbcon.c > >> @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; > >> static int fbcon_is_default = 1; > >> static int fbcon_has_exited; > >> static int primary_device = -1; > >> +#ifndef MODULE > > > > Disrecard my other comment. This should be > > > > #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY > > You really sure ? Yes, I realize that. I already have a patch in my tree that will fix this properly. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Tue, 2007-07-24 at 22:45 +0100, Adrian McMenamin wrote:
> On 23/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote:
> > > I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17
> > > - when the code is executed it appears to lock the Dreamcast up.
> > >
> > > The problem seems to be:
> > >
> > > fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> > >
> > > In drivers/video/fbmem.c
> > >
> > > This hasn't been an issue before, so are there any recent changes that
> > > might have caused this?
> >
> > What's the last kernel that worked for you? Can you also post your
> > config?
> >
> > >
> > > (fb_notifier_call_chain calls a succession of stubs ending in
> > > __blocking_notifier_call_chain in kernel/sys.c)
> > >
> >
> > Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3.
> >
> > Tony
> >
>
> Tony,
>
> I have checked this a few times now, including against Paul's git as
> well as Linus's and the Dreamcast won't boot without its reversion.
> Don't know why, but it needs to be reverted until a better fix is
> available.
I'm also confused. Can you change the color depth to 32 bpp ('fbset
-depth 32')? I'm thinking of a possible pseudo_palette overrun.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Thu, 2007-08-02 at 22:33 -0400, Daniel Drake wrote:
> Antonino A. Daplas wrote:
> > How about this patch?
> >
> > Tony
> > ---
> >
> > Subject: video setup: Fix VBE DDC reading
> >
> > Add memory operand constraint and write-only modifier to the inline
> > assembly to effect the writing of the EDID block to boot_params.edid_info.
>
>
> Thanks, this patch works in that Linux now reports the correct resolution.
>
> However, the TV output is now scrambled...
The previous problem was just a display shift of 6 pixels, correct? If
the display is now scrambled, then this is a new problem.
> I suspect this might be a result of adding CONFIG_FRAMEBUFFER_CONSOLE in
> the most recent tests.
It's useless to unset CONFIG_FRAMEBUFFER_CONSOLE to 'n', he'll just end
up with a 640x400 stretched or windowed display.
Can he...
1. describe what 'scrambled' means?
2. Boot with video=intelfb:accel=0,?
3. post the output of 'fbset -i' and the latest dmesg?
4. change the color depth ('fbset -depth 16')?
5. If possible, run X using 'fbdev' as the driver at 16 bpp
(I don't think 32 bpp works with X-fbdev)?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sat, 2007-08-04 at 11:06 -0700, H. Peter Anvin wrote: > Linus Torvalds wrote: > > > > On Sat, 4 Aug 2007, Jeff Chua wrote: > >> On 8/4/07, Jeff Chua <[EMAIL PROTECTED]> wrote: > After resume from s2ram or switching to console from X, my console is > messed up on rc1 and rc2. Is there a fix for this? > >>> This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a > >>> known problem, than I don't need to bisect all over again. > >> I managed to bisect down to this commit. Without this, console screen > >> can resume without video mess. > > > > [ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: "Use the new > > x86 setup code for i386" ] > > > > Very interesting. > > > > Jeff - do I understand correctly that the "or" means that even *without* a > > suspend-to-ram sequence, and just by going into X and then going back to > > text-mode, the screen is corrupt? > > Also, can you please describe "messed up" in more detail? We had one > report of "screen messed up" already that did get fixed > (CONFIG_FIRMWARE_EDID not working.) I believe this is the case where VBE DDC reading is non-contributory. > > Are you using the VGA console or a framebuffer console? > > Also, please submit your .config and kernel command line. The dmesg output, the X logs and the s2ram options will also be useful. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sun, 2007-08-05 at 20:11 +0800, Jeff Chua wrote: > On 8/5/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > > Also, please submit your .config and kernel command line. > > # cat /proc/cmdline > > BOOT_IMAGE=(hd0,14)/linux/bzc1 root=/dev/sda2 resume=/dev/sda3 reboot=bios > > Can you try with the boot option acpi_sleep=s3_bios,s3_mode OR if using s2ram, use s2ram -f a3 Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > With the patch reverted and 24bpp, it oopses before freezing (with two > > odd looking boot logos on the screen): > > > Tested this further and it fails on: > > rev = fb_readl(par->mmio_base + 0x04); Doubtful if this line is the point of failure, this line is executed only once, on initialization. > > Will try to see what's up - but if anyone knows what is likely to be > wrong here please shout out! I'm still thinking there's something wrong on how the resources are allocated causing a pseudo_palette overrun. I'll post a clean-up patch later. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 20:47 +0100, Adrian McMenamin wrote:
> On 26/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
>
> >
> > I'm also confused. Can you change the color depth to 32 bpp ('fbset
> > -depth 32')? I'm thinking of a possible pseudo_palette overrun.
> >
>
> The code behaves in exactly the same way with the bit depth set to 32
> and without the patch reversion (ie forces a reboot).
>
> With the parch reverted there is a flicker of output on the screen
> before a reboot is forced (it will boot with 16bpp though the colour
> is a bit iffy)
>
> With the patch reverted and 24bpp, it oopses before freezing (with two
> odd looking boot logos on the screen):
Can you try the attached patch? It's just a clean-up patch: uses
framebuffer_alloc/release instead of kmalloc.
Tony
diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index f930026..a72921b 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -143,6 +143,7 @@ static struct pvr2fb_par {
unsigned char is_lowres; /* Is horizontal pixel-doubling enabled? */
unsigned long mmio_base; /* MMIO base */
+ u32 palette[16];
} *currentpar;
static struct fb_info *fb_info;
@@ -790,7 +791,7 @@ static int __devinit pvr2fb_common_init(
fb_info->fbops = &pvr2fb_ops;
fb_info->fix = pvr2_fix;
fb_info->par = currentpar;
- fb_info->pseudo_palette = (void *)(fb_info->par + 1);
+ fb_info->pseudo_palette = currentpar->palette;
fb_info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
if (video_output == VO_VGA)
@@ -1082,14 +1083,15 @@ #ifndef MODULE
#endif
size = sizeof(struct fb_info) + sizeof(struct pvr2fb_par) + 16 * sizeof(u32);
- fb_info = kzalloc(size, GFP_KERNEL);
+ fb_info = framebuffer_alloc(sizeof(struct pvr2fb_par), NULL);
+
if (!fb_info) {
printk(KERN_ERR "Failed to allocate memory for fb_info\n");
return -ENOMEM;
}
- currentpar = (struct pvr2fb_par *)(fb_info + 1);
+ currentpar = fb_info->par;
for (i = 0; i < ARRAY_SIZE(board_driver); i++) {
struct pvr2_board *pvr_board = board_driver + i;
@@ -1102,7 +1104,7 @@ #endif
if (ret != 0) {
printk(KERN_ERR "pvr2fb: Failed init of %s device\n",
pvr_board->name);
- kfree(fb_info);
+ framebuffer_release(fb_info);
break;
}
}
@@ -1126,7 +1128,7 @@ #ifdef CONFIG_SH_STORE_QUEUES
#endif
unregister_framebuffer(fb_info);
- kfree(fb_info);
+ framebuffer_release(fb_info);
}
module_init(pvr2fb_init);
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: > On 27/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > > > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > > > > > With the patch reverted and 24bpp, it oopses before freezing (with two > > > > odd looking boot logos on the screen): > > > > > > > Tested this further and it fails on: > > > > > > rev = fb_readl(par->mmio_base + 0x04); > > > > Doubtful if this line is the point of failure, this line is executed > > only once, on initialization. > > > par->mmio_base is corrupted in some way during the call to > register_framebuffer - still investigating how/why. Possible, par->mmio_base is the last field in struct pvr2fb_par, after that is the pseudo_palette. The oops did not manifest when the pseudo_palette was written as u16, but oops'ed when written as u32. Memory alignment problems? Try the patch I posted before, might help. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 01:32 +0100, Adrian McMenamin wrote: > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: > > > On 27/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > > > > > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > With the patch reverted and 24bpp, it oopses before freezing (with > > > > > > two > > > > > > odd looking boot logos on the screen): > > > > > > > > > > > Tested this further and it fails on: > > > > > > > > > > rev = fb_readl(par->mmio_base + 0x04); > > > > > > > > Doubtful if this line is the point of failure, this line is executed > > > > only once, on initialization. > > > > > > > > > par->mmio_base is corrupted in some way during the call to > > > register_framebuffer - still investigating how/why. > > > > Possible, par->mmio_base is the last field in struct pvr2fb_par, > > after that is the pseudo_palette. The oops did not manifest when the > > pseudo_palette was written as u16, but oops'ed when written as u32. > > Memory alignment problems? > > > > Try the patch I posted before, might help. > > > Apologies, missed the patch before. > > With the patch applied the Dreamcast no longer crashes or locks with > either 16, 24 or 32 bpp, so that's good. > > With 24bpp everything is doubled up (eg two boot logos on screen) and > about twice (?) the size it should be - though with a black screen. > > With 32 bpp everything is about 4 (?) times the size it should be and > all on a yellow background. > > With 16bpp then everything is on a blue background as before, but is > also the correct size (as before). Is this with commit a66ad56eb2c9644717da4d7f05f971d6786145e3 reverted? Reapply this commit again, it might (fingers crossed) correct the color problem. As to your display doubling/quadrupling with bpp 24/32, I don't have any answers (no hardware) though it seems to be a framebuffer pitch/display width mismatch. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > But certainly better at 16bpp > > Can mess about with it later to see if I can get the colours right I suppose. > You can start with pvr2fb_setcolreg() and pvr2fb_set_pal_entry(). A few things I've noticed: 1. In pvr2fb_setcolreg(), pvr2fb_set_pal_entry() is called for bpp 16 and 32. This means that the palette is modifiable, so FB_VISUAL_TRUECOLOR is probably not the correct visual for this driver, FB_VISUAL_DIRECTCOLOR is more appropriate. So, you either remove the call to set_pal_entry() in setcolreg() or change the visual to FB_VISUAL_DIRECTCOLOR. Of course, with directcolor, the pseudo_palette is now written with tmp as: tmp = transp << var->transp.offset | red << var->red.offset | green << var->green.offset | blue << var->green.offset; 2. Perhaps, the 3rd parameter passed to set_pal_entry() is not correct? Maybe you can try doing it like this for all bpp's, assuming ARGB? pvr2fb_set_pal_entry(par, regno, transp << 24 | red << 16 | green << 8 | blue); And if you want to maintain FB_VISUAL_TRUECOLOR format, initialize the palette once on init: for (i = 0; i < 256; i++) pvr2fb_set_pal_entry(par, i, i << 24 | i << 16 | i << 8 | i); to create a linear color map consistent with truecolor, then remove all other calls to pvr2fb_set_pal_entry(). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 10:14 +0800, Antonino A. Daplas wrote: > On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: > > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > > > tmp = transp << var->transp.offset | red << var->red.offset | > green << var->green.offset | blue << var->green.offset; > The above should be: tmp = regno << var->transp.offset | regno << var->red.offset | regno << var->green.offset | regno << var->green.offset; Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Framebuffer: Consolidated cleanup of pvr2fb.c for Sega Dreamcast
On Tue, 2007-07-31 at 04:48 +0900, Paul Mundt wrote: > On Sun, Jul 29, 2007 at 01:39:51AM +0100, Adrian McMenamin wrote: > This looks fine to me in any event. I can either wrap this up in my tree > or Tony can include it with his next set of updates if he has any other > concerns. Thanks, Adrian. > > Acked-by: Paul Mundt <[EMAIL PROTECTED]> I'll do the merge and push to mainline. This patch is really composed of three changes (one is already in mainline, the second is a resource allocation clean-up, and the third is Adrian's change). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 19:58 -0400, Daniel Drake wrote: > Hi, > > H. Peter Anvin wrote: > >> So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are > >> further patches needed? > >> > > > > It should, yes. > > It didn't work, and the bug still exists in 2.6.23-rc1: the resolution > is wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. > > So far the only known working setups since 2.6.20.11 are: > 1. Zwane's patch reverted > 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works > for 2.6.23) > > Here is dmesg output from 2.6.23: > http://bugs.gentoo.org/attachment.cgi?id=126203&action=view > The dmesg ouput did show that intelfb was not able to acquire the EDID from the BIOS, even if CONFIG_FIRMWARE_EDID=y I presume. I don't think it's the VBE version, the chipset is an Intel 830 which should at least be a VBE 2.0. Is it the same for the working kernel? Do you have a link to the dmesg ouput of a working kernel, if possible with #define DEBUG in drivers/video/fbmon.c. The output of read-edid or /var/log/X?.log will also be helpful. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: > Zwane Mwaikambo wrote: > > Sorry if this has been hashed out before, but could you point me towards > > the gentoo bugzilla entry? I'm trying to understand how your setup broke. > > Which version VBE does your system have? > > Here's the bug: > http://bugs.gentoo.org/show_bug.cgi?id=181067 > Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. > How can we identify the VBE version? If vesafb works, then it is at least VBE 2.0. To confirm, you can use X + the 'vesa' driver and check /var/log/X*.log. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86_64 EFI support -v3: EFI framebuffer driver
On Tue, 2007-07-31 at 11:13 +0800, Huang, Ying wrote: > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + I don't see any problems with this driver, just a few minor nits. Do you really need all the #include's? I presume this driver only supports bpp 16 and above? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: > On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: > > Zwane Mwaikambo wrote: > > > Sorry if this has been hashed out before, but could you point me towards > > > the gentoo bugzilla entry? I'm trying to understand how your setup broke. > > > Which version VBE does your system have? > > > > Here's the bug: > > http://bugs.gentoo.org/show_bug.cgi?id=181067 > > > > Looking at the dmesg output of the working and failing kernel, it does > seem that there's no EDID block available in the failing kernel. > BTW, I looked at the above bug report, it seems his last dmesg does not have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before doing more tests (the problem of lack of the EDID block in the failing kernel still applies). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
H. Peter Anvin wrote: > Antonino A. Daplas wrote: >> On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: >>> On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: >>>> Zwane Mwaikambo wrote: >>>>> Sorry if this has been hashed out before, but could you point me >>>>> towards the gentoo bugzilla entry? I'm trying to understand how >>>>> your setup broke. Which version VBE does your system have? >>>> Here's the bug: >>>> http://bugs.gentoo.org/show_bug.cgi?id=181067 >>>> >>> Looking at the dmesg output of the working and failing kernel, it does >>> seem that there's no EDID block available in the failing kernel. >>> >> >> BTW, I looked at the above bug report, it seems his last dmesg does not >> have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before >> doing more tests (the problem of lack of the EDID block in the failing >> kernel still applies). >> > > Okay, I'm royally puzzled why that would be. I've gone over the code > quite a few times, and I do not see any way (other than VESA < 2.0) that > could cause that. > > I look forward to getting the debug output; depending on what it is we > might have to get some debugging output from the setup code. > > We can printf in the new setup code, although obviously that requires > leaving the screen in text mode. However, EDID information should still > be available. > How about this patch? Tony --- Subject: video setup: Fix VBE DDC reading Add memory operand constraint and write-only modifier to the inline assembly to effect the writing of the EDID block to boot_params.edid_info. Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]> --- arch/i386/boot/video-vesa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c index e6aa9eb..f1bc71e 100644 --- a/arch/i386/boot/video-vesa.c +++ b/arch/i386/boot/video-vesa.c @@ -268,7 +268,7 @@ #ifdef CONFIG_FIRMWARE_EDID dx = 0; /* EDID block number */ di =(size_t) &boot_params.edid_info; /* (ES:)Pointer to block */ asm(INT10 - : "+a" (ax), "+b" (bx), "+d" (dx) + : "+a" (ax), "+b" (bx), "+d" (dx), "=m" (boot_params.edid_info) : "c" (cx), "D" (di) : "esi"); #endif /* CONFIG_FIRMWARE_EDID */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING
On Mon, 2007-08-13 at 11:03 -0700, Joe Perches wrote: > > > +F: drivers/video/svgalib.c > > > +F: include/linux/svga.h > > These two are not a part of the video mode selection code, but > > arch/i386/boot/video.S is. > > SVGA HANDLING > P:Martin Mares > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > S:Maintained > F:Documentation/svga.txt > F:arch/i386/boot/video.S video.S is no more. Replaced by arch/i386/boot/video-*.c Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad addresses in MAINTAINERS
On Mon, 2007-08-13 at 12:07 -0700, Joe Perches wrote: > > INTEL FRAMEBUFFER DRIVER (excluding 810 and 815) > P:Sylvain Meyer > M:[EMAIL PROTECTED] > Maybe Dave? > IMS TWINTURBO FRAMEBUFFER DRIVER > P:Paul Mundt > M:[EMAIL PROTECTED] That's not Paul's current email. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > While running a test with current Linus' git tree, I ran into the following > issue. The issue is also present in stable 2.6.23. > > System x86_64; Pentium D; Intel 82945G/GZ on-board graphics > > After initial boot messages all output to console stops. The last visible > messages are: > checking if image is initramfs...<6>Switched to high resolution mode on CPU 1 > Switched to high resolution mode on CPU 0 > > After that, nothing until XOrg starts up and graphical login/desktop on VT7 > are displayed normal. > Switching back to VT1-VT5 gives nothing: no login prompts, just nothing. > Can you also post your dmesg and /proc/cdmline? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > I could solve this issue in two ways: > - boot with VGA=791 parameter (initial boot was without VGA= parameter) > - compile kernel without FRAMEBUFFER_CONSOLE_DETECT_PRIMARY set (I also > unset FB_VIRTUAL, but without its boot param that should be a no-op) After looking at vfb.c again, it seems the default is for vfb to be enabled and you have to actively disable vfb either with video=vfb:disable or video=vfb:off I have to change this behavior. In the meantime, try one of the above options. (I was also under the impression that vfb must be explicitly enabled with a boot option...I remember now, the option vfb_enable defaults to false when compiled as a module, and to true if compiled statically.) Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Remove the use of magic macros for boot_params/screen_info
On Tue, 2007-10-16 at 23:56 -0700, H. Peter Anvin wrote: > Hi Linus, > > Please pull: > > git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git > master > > This patch removes all uses of magic macros to access the former > zeropage, now the boot_params structure, as well as the screen_info > structure. The equivalent (pre-x86-merge) of the boot_params patch > has been in -mm since shortly after 2.6.22. > > A minor note: the video mode number 0x6A was officially assigned by > VESA; the only VESA standard 7-bit video mode number ever assigned. > > H. Peter Anvin (2): > [x86] remove uses of magic macros for boot_params access > Remove magic macros for screen_info structure members > > drivers/video/console/dummycon.c |4 +- > drivers/video/console/vgacon.c | 51 ++- > drivers/video/intelfb/intelfbdrv.c | 5 ++- > drivers/video/vga16fb.c|2 +- Acked-by: Antonino A. Daplas <[EMAIL PROTECTED]> with respect to the drivers/video portion. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: > On 2/6/07, James Simmons <[EMAIL PROTECTED]> wrote: > > > > If you can find post the manufacturer and model number we can place it on > > the backlist in fbmon. Also we should figure out what is wrong and fix it. > > It's the UltraSharp UXGA display that used to come with Dell Inspiron > 8200, 15" with a resolution of 1600x1200. I've been looking all around > for more info on it, but the only things I could find were posts that > remarked the problems Windows nVidia drivers have with some of these > (no image when running at 1600x1200), and other posts about banded > gradients with Windows drivers on Radeon video cards (but I get banded > gradients also win my nVidia card, on Linux, regardless of which > driver I use, binary, nv or nouveau). > > As mentioned in another post in this thread, I can't get any info out > of the i2c busses, because even when I have them available (i.e. after > loading nvidiafb) I get all around (on all three of them). > Suggestions on how to get the information welcome. Is this the same monitor you posted here? http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2 If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard. I already have a patch for this which I forgot to send to you before :-). If you can confirm that this is still the same hardware, I'll send you a test patch Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote: > On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > Given that, this would have to be something that's dealt with at the > > subsystem level rather than in individual drivers, hence the desire to > > see something like this more generically visible. > > > > Hi Peter, Paul, fbdev folk, > > Ok. Here's what I'm thinking for abstracting this: > > fbdev drivers would setup fb_mmap with their own_mmap as usual. In > own_mmap, they would do what they normally do and setup a vm_ops. They > are free to have their own nopage handler but would set the > page_mkwrite handler to be fbdev_deferred_io_mkwrite(). > fbdev_deferred_io_mkwrite would build up the list of touched pages and > pass it to a delayed workqueue which would then mkclean on each page Yes, this functionality is sorely needed by more than a few driver writers. > and then pass a copy of that page list down to a driver's callback > function. The fbdev driver's callback function can then do the actual > IO to the framebuffer or coalesce DMA based on the provided page list. > I would like to add something like the following to struct fb_info: > > #ifdef CONFIG_FB_DEFERRED_IO > struct fb_deferred_io *defio; > #endif > > to store the mutex (to protect the page list), the touched page list, > and the driver's callback function. > > I hope this sounds sufficiently generic to meet everyone's (the two of > us? :) needs. There's definitely more than two :-). For the past several years, various people have been asking for this functionality. So yes, implementing this in a generic manner will be a big help. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote:
> On 2/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > Don't you need a way to specify the maximum deferral time? E.g. a field in
> > fb_info.
> >
>
> You are right. I will need that. I could put that into struct
> fb_deferred_io. So drivers would setup like:
>
Is it also possible to let the drivers do the 'deferred_io'
themselves? Say, a driver that would flush the dirty pages on
every VBLANK interrupt.
> static struct fb_deferred_io hecubafb_defio = {
> .delay = HZ,
> .deferred_io= hecubafb_dpy_update,
> };
>
> where that would be:
> struct fb_deferred_io {
> unsigned long delay;/* delay between mkwrite and deferred handler
> */
> struct mutex lock; /* mutex that protects the page list */
> struct list_head pagelist; /* list of touched pages */
> struct delayed_work deferred_work;
> void (*deferred_io)(struct fb_info *info, struct list_head
> *pagelist); /* callback */
> };
>
> and the driver would do:
> ...
> info->fbdefio = hecubafb_defio;
> register_framebuffer...
>
> When the driver calls register_framebuffer and unregister_framebuffer,
> I can then do the init and destruction of the other members of that
> struct. Does this sound okay?
It would be better if separate registering functions are created for
this functionality (ie deferred_io_register/unregister).
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume
On Thu, 2007-02-15 at 13:00 +0200, S.Çağlar Onur wrote: > 15 Şub 2007 Per tarihinde, Andrew Morton şunları yazmıştı: > > On Thu, 15 Feb 2007 11:40:32 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > > > Contact fbcon people... > > > > There aren't any, basically. Since Tony disappeared James has been helping > > out but doesn't have a lot of time. So we're pretty much on our own with > > problems in this area. > > I already sent same mail to > linux-fbdev-devel mailing lists at sf.net with hope :) > > Cheers Interesting... It does look like this was triggered by calling do_blank_screen() without taking the console semaphore, but console_callback() should have taken that. Second point is that vesafb does not have any blanking functionality, thus it should not trigger fbcon_event_notify(). My guess is you are using an out-of-tree vesafb? BUG: at drivers/char/vt.c:3332 do_blank_screen() [] do_blank_screen+0x4e/0x218 [] fbcon_event_notify+0x8f1/0xa1e [] extract_buf+0xac/0xe1 [] __switch_to+0xeb/0x15d [] __sched_text_start+0x865/0x929 [] bit_cursor+0x4c8/0x50b [] wait_for_completion+0x79/0xaf [] default_wake_function+0x0/0xc [] notifier_call_chain+0x19/0x32 [] blocking_notifier_call_chain+0x23/0x33 [] fb_blank+0x4a/0x53 [] fbcon_blank+0xf4/0x1e3 [] fbcon_cursor+0x21c/0x250 [] bit_cursor+0x0/0x50b [] lock_timer_base+0x15/0x2f [] try_to_del_timer_sync+0x44/0x4a [] fbcon_blank+0x0/0x1e3 [] do_blank_screen+0x1b1/0x218 [] console_callback+0xaf/0xbf [] run_workqueue+0x85/0x135 [] console_callback+0x0/0xbf [] worker_thread+0x10a/0x136 [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x136 [] kthread+0xb2/0xdc [] kthread+0x0/0xdc [] kernel_thread_helper+0x7/0x10 As for the last tracing, it looks to be valid bug to me. complete_change_console() should be called with the console sem taken. I'll look into this. BUG: at drivers/char/vt.c:3486 set_palette() [] set_palette+0x41/0x59 [] redraw_screen+0x110/0x17e [] complete_change_console+0x2a/0xba [] console_callback+0x45/0xbf [] run_workqueue+0x85/0x135 [] console_callback+0x0/0xbf [] worker_thread+0x10a/0x136 [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x136 [] kthread+0xb2/0xdc [] kthread+0x0/0xdc [] kernel_thread_helper+0x7/0x10 Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
> This patch adds driver for S3 Trio / S3 Virge. Driver is tested
> with most versions of S3 Trio and S3 Virge, on i386.
> It is tested both as compiled-in and module. It is against
> linux-2.6.20 .
>
> This is version 3. There are some minor modifications from version 2
> (mostly coding style cleanups).
Nice, the first driver to use tileblit :-)
Since this driver is already in the -mm tree, can you resubmit a diff
against that?
> +
> +static const struct vga_regset s3_h_total_regs[]= {{0x00, 0, 7},
> {0x5D, 0, 0}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_display_regs[] = {{0x01, 0, 7},
> {0x5D, 1, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_blank_start_regs[] = {{0x02, 0, 7},
> {0x5D, 2, 2}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_blank_end_regs[]= {{0x03, 0, 4},
> {0x05, 7, 7}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_sync_start_regs[] = {{0x04, 0, 7},
> {0x5D, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_sync_end_regs[] = {{0x05, 0, 4},
> VGA_REGSET_END};
> +
> +static const struct vga_regset s3_v_total_regs[]= {{0x06, 0, 7},
> {0x07, 0, 0}, {0x07, 5, 5}, {0x5E, 0, 0}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_display_regs[] = {{0x12, 0, 7},
> {0x07, 1, 1}, {0x07, 6, 6}, {0x5E, 1, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_blank_start_regs[] = {{0x15, 0, 7},
> {0x07, 3, 3}, {0x09, 5, 5}, {0x5E, 2, 2}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_blank_end_regs[]= {{0x16, 0, 7},
> VGA_REGSET_END};
> +static const struct vga_regset s3_v_sync_start_regs[] = {{0x10, 0, 7},
> {0x07, 2, 2}, {0x07, 7, 7}, {0x5E, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_sync_end_regs[] = {{0x11, 0, 3},
> VGA_REGSET_END};
> +
> +static const struct vga_regset s3_line_compare_regs[] = {{0x18, 0, 7},
> {0x07, 4, 4}, {0x09, 6, 6}, {0x5E, 6, 6}, VGA_REGSET_END};
> +static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7},
> {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7},
> {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
> +
Within reason, try to limit each line to 80 columns.
> +
> +/* image data is MSB-first, fb structure is MSB-first too */
> +static inline u32 expand_color(u32 c)
> +{
> + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> 0xFF;
> +}
> +
> +/* s3fb_iplan_imageblit silently assumes that almost everything is 8-pixel
> aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
> +
> +static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> + u_int transp, struct fb_info *fb)
> +{
> + switch (fb->var.bits_per_pixel) {
> + case 0:
> + case 4:
> + if (regno >= 16)
> + return -EINVAL;
> +
> + if ((fb->var.bits_per_pixel == 4) &&
> + (fb->var.nonstd == 0)) {
> + outb(0xF0, VGA_PEL_MSK);
> + outb(regno*16, VGA_PEL_IW);
> + } else {
> + outb(0x0F, VGA_PEL_MSK);
> + outb(regno, VGA_PEL_IW);
> + }
> + outb(red >> 10, VGA_PEL_D);
> + outb(green >> 10, VGA_PEL_D);
> + outb(blue >> 10, VGA_PEL_D);
> + break;
> + case 8:
> + if (regno >= 256)
> + return -EINVAL;
> +
> + outb(0xFF, VGA_PEL_MSK);
> + outb(regno, VGA_PEL_IW);
> + outb(red >> 10, VGA_PEL_D);
> + outb(green >> 10, VGA_PEL_D);
> + outb(blue >> 10, VGA_PEL_D);
> + break;
> + case 16:
> + if (regno >= 16)
> + return -EINVAL;
Just return success without doing anything. I presume this is
truecolor.
> +
> + if (fb->var.green.length == 5)
> + ((u32*)fb->pseudo_palette)[regno] = ((red & 0xF800) >>
> 1) |
> + ((green & 0xF800) >> 6) | ((blue & 0xF800) >>
> 11);
> + else if (fb->var.green.length == 6)
> + ((u32*)fb->pseudo_palette)[regno] = (red & 0xF800) |
> + ((green & 0xFC00) >> 5) | ((blue & 0xF800) >>
> 11);
> + else return -EINVAL;
Same here.
> + break;
> + case 24:
> + case 32:
> + if (regno >= 16)
> + return -EINVAL;
And here.
> +
> + ((u32*)fb->pseudo_palette)[regno] = ((transp & 0xFF00) << 16) |
> ((red & 0xFF00) << 8) |
> + (green & 0xFF00) | ((blue & 0xFF00) >> 8);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
Re: [Linux-fbdev-devel] [PATCH]
On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> This is the new display intreface. Its goal is to provide a standard
> interface to various types of displays. Currently we have auxdisplay,
> output acpi device and the now defunct lcd class in the backlight directory.
> Please apply.
Is this an attempt to consolidate all display hardware and drivers?
>
[snip]
> +struct class *display_class;
> +EXPORT_SYMBOL(display_class);
> +static int index;
> +
> +struct display_device *display_device_register(struct display_driver *driver,
> + struct device *dev, void
> *devdata)
> +{
> + struct display_device *new_dev = NULL;
> + int ret = -EINVAL;
> +
> + if (unlikely(!driver))
> + return ERR_PTR(ret);
> +
> + new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
> + if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
> + new_dev->dev = device_create(display_class, dev, 0,
> + "display%d", index);
> +
> + if (!IS_ERR(new_dev->dev)) {
> + dev_set_drvdata(new_dev->dev, new_dev);
> + new_dev->driver = driver;
> + new_dev->parent = dev;
> + mutex_init(&new_dev->lock);
> + index++;
> + } else {
> + new_dev->dev = NULL;
> + kfree(new_dev);
Set new_dev to NULL on failure.
> + }
> + }
> + return new_dev;
> +}
> +EXPORT_SYMBOL(display_device_register);
> +
> +void display_device_unregister(struct display_device *ddev)
> +{
> + if (!ddev)
> + return;
> + mutex_lock(&ddev->lock);
> + device_del(ddev->dev);
> + ddev->driver = NULL;
> + index--;
display0
display1
index = 2
unregister display0
index = 1
display_device_register() as device1
device1 <-- BUG, already used.
[snip]
> +
> +struct display_device;
> +
> +/* This structure defines all the properties of a Display. */
> +struct display_driver {
> + int (*set_contrast)(struct display_device *, unsigned int);
> + int (*get_contrast)(struct display_device *);
> + void (*suspend)(struct display_device *, pm_message_t state);
> + void (*resume)(struct display_device *);
> + int (*probe)(struct display_device *, void *);
> + int (*remove)(struct display_device *);
> + int max_contrast;
If this is an attempt to consolidate, I don't see the 'brightness'
hook of backlight and lcd.
If this is not a consolidation, why don't we just extend the lcd class?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
> > > +/* image data is MSB-first, fb structure is MSB-first too */
> > > +static inline u32 expand_color(u32 c)
> > > +{
> > > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> > > 0xFF;
> > > +}
> > > +
> > > +/* s3fb_iplan_imageblit silently assumes that almost everything is
> > > 8-pixel aligned */
> >
> > Hmn, same thing with vga16fb... Perhaps we should bring back the
> > fontwidth flag of 2.2 and 2.4 kernels.
>
> Ug no. It is possible to get 12,6 bit width fonts working with vga
> interleaved planes. I got it paritally working but never got back to it.
> Its in my queue of this to do. Now that I finished the display class I
> need to get around to makeing drm/fbdev work together :-)
>
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH]
On Thu, 2007-02-22 at 01:35 +, James Simmons wrote: > > On Wed, 2007-02-21 at 21:23 +, James Simmons wrote: > > If this is an attempt to consolidate, I don't see the 'brightness' > > hook of backlight and lcd. > > > > If this is not a consolidation, why don't we just extend the lcd class? > > Its is a replacement for lcd. Is brightness universal for all display > types? Well, if you're adding a universal interface, you need hooks for more than that (brightness, contrast, hue, saturation, tint, etc). Then we just let the drivers cherry pick from the list on what it's going to support. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 09:01 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> > >
> > > As mentioned in another post in this thread, I can't get any info out
> > > of the i2c busses, because even when I have them available (i.e. after
> > > loading nvidiafb) I get all around (on all three of them).
> > > Suggestions on how to get the information welcome.
> >
> > Is this the same monitor you posted here?
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2
> >
> > If yes, we already have the manufacturer and model code. The main
> > problem is that the EDID of this display has no sync range (H: 75-75kHz
> > and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID
> > block shouldn't be too hard.
>
> Yes, that's it! Jeepers, I can't believe that even re-reading the past
> LKML posts (even those!) I couldn't find the EDID info and how we had
> gotten them. I guess I need stronger glasses.
>
> Wonder why Luca's proposed patch makes the EDID undetectable, now, and
> why can't it be retrieved at a later time via i2c. Timeouts too small?
>
> > I already have a patch for this which I forgot to send to you
> > before :-). If you can confirm that this is still the same hardware,
> > I'll send you a test patch
>
> Yes, it's the same hardware. I can try the patch, with or without Luca's.
>
>
Okay. Patch attached. You may want to #define DEBUG in
drivers/video/fbmon.c so we can appreciate what happens. Load nvidiafb
with DEBUG defined before and after applying the patch, then send your
'dmesg'.
Tony
fbdev: Add Ultrasharp UXGA to broken monitor database
From: <>
This particular monitor does not have a limits block and has only one set of
monitor timings. Fix by adding a limits block to the EDID and extend the
horizontal sync frequency range to 30 kHz and 75 Khz.
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
drivers/video/fbmon.c | 168 +
1 files changed, 112 insertions(+), 56 deletions(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 6b385c3..05a9464 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -48,8 +48,9 @@ #else
#define DPRINTK(fmt, args...)
#endif
-#define FBMON_FIX_HEADER 1
-#define FBMON_FIX_INPUT 2
+#define FBMON_FIX_HEADER 1
+#define FBMON_FIX_INPUT 2
+#define FBMON_FIX_TIMINGS 3
#ifdef CONFIG_FB_MODE_HELPERS
struct broken_edid {
@@ -71,6 +72,12 @@ static const struct broken_edid brokendb
.model= 0x5a44,
.fix = FBMON_FIX_INPUT,
},
+ /* Sharp UXGA? */
+ {
+ .manufacturer = "SHP",
+ .model= 0x138e,
+ .fix = FBMON_FIX_TIMINGS,
+ },
};
static const unsigned char edid_v1_header[] = { 0x00, 0xff, 0xff, 0xff,
@@ -87,6 +94,55 @@ static void copy_string(unsigned char *c
while (i-- && (*--s == 0x20)) *s = 0;
}
+static int edid_is_serial_block(unsigned char *block)
+{
+ if ((block[0] == 0x00) && (block[1] == 0x00) &&
+ (block[2] == 0x00) && (block[3] == 0xff) &&
+ (block[4] == 0x00))
+ return 1;
+ else
+ return 0;
+}
+
+static int edid_is_ascii_block(unsigned char *block)
+{
+ if ((block[0] == 0x00) && (block[1] == 0x00) &&
+ (block[2] == 0x00) && (block[3] == 0xfe) &&
+ (block[4] == 0x00))
+ return 1;
+ else
+ return 0;
+}
+
+static int edid_is_limits_block(unsigned char *block)
+{
+ if ((block[0] == 0x00) && (block[1] == 0x00) &&
+ (block[2] == 0x00) && (block[3] == 0xfd) &&
+ (block[4] == 0x00))
+ return 1;
+ else
+ return 0;
+}
+
+static int edid_is_monitor_block(unsigned char *block)
+{
+ if ((block[0] == 0x00) && (block[1] == 0x00) &&
+ (block[2] == 0x00) && (block[3] == 0xfc) &&
+ (block[4] == 0x00))
+ return 1;
+ else
+ return 0;
+}
+
+static int edid_is_timing_block(unsigned char *block)
+{
+ if ((block[0] != 0x00) || (block[1] != 0x00) ||
+ (block[2] != 0x00) || (block[4] != 0x00))
+ return 1;
+ else
+ return 0;
+}
+
static int check_edid(unsigned char *edid)
{
unsigned char *block = edid + ID_MANUFACTURER_NAME, manufacturer[4];
@@ -104,9 +160,6 @@ static int check_edid(unsigned char *edi
for (i = 0; i < ARRAY
Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume
On Thu, 2007-02-22 at 14:53 +0200, S.Çağlar Onur wrote: > Hi; > > 22 Şub 2007 Per tarihinde, Antonino A. Daplas şunları yazmıştı: > > On Thu, 2007-02-15 at 13:00 +0200, S.Çağlar Onur wrote: > > > 15 Şub 2007 Per tarihinde, Andrew Morton şunları yazmıştı: > > > > On Thu, 15 Feb 2007 11:40:32 +0100 Pavel Machek <[EMAIL PROTECTED]> > > > > wrote: > > > > > Contact fbcon people... > > > > > > > > There aren't any, basically. Since Tony disappeared James has been > > > > helping out but doesn't have a lot of time. So we're pretty much on > > > > our own with problems in this area. > > > > > > I already sent same mail to > > > linux-fbdev-devel mailing lists at sf.net with hope :) > > > > > > Cheers > > > > Interesting... It does look like this was triggered by calling > > do_blank_screen() without taking the console semaphore, but > > console_callback() should have taken that. > > > > Second point is that vesafb does not have any blanking functionality, > > thus it should not trigger fbcon_event_notify(). My guess is you are > > using an out-of-tree vesafb? > > As i wrote we are using vesafb-tng [http://dev.gentoo.org/~spock/projects/] > for a long time but this hits me only with 2.6.20 and only after > suspend2disk, so im adding Michał Januszewski to CC if this is vesafb-tng > related :). > Ah, and you have fb_splash too. That's why the tracing was not what I expected it to be. Try using video=vesafb:noblank to disable hardware blanking and find out if you can still reproduce the oops. > > BUG: at drivers/char/vt.c:3332 do_blank_screen() > > [] do_blank_screen+0x4e/0x218 > > [] fbcon_event_notify+0x8f1/0xa1e > > [] extract_buf+0xac/0xe1 > > [] __switch_to+0xeb/0x15d > > [] __sched_text_start+0x865/0x929 > > [] bit_cursor+0x4c8/0x50b > > [] wait_for_completion+0x79/0xaf > > [] default_wake_function+0x0/0xc > > [] notifier_call_chain+0x19/0x32 > > [] blocking_notifier_call_chain+0x23/0x33 > > [] fb_blank+0x4a/0x53 > > [] fbcon_blank+0xf4/0x1e3 > > [] fbcon_cursor+0x21c/0x250 > > [] bit_cursor+0x0/0x50b > > [] lock_timer_base+0x15/0x2f > > [] try_to_del_timer_sync+0x44/0x4a > > [] fbcon_blank+0x0/0x1e3 > > [] do_blank_screen+0x1b1/0x218 > > [] console_callback+0xaf/0xbf > > [] run_workqueue+0x85/0x135 > > [] console_callback+0x0/0xbf > > [] worker_thread+0x10a/0x136 > > [] default_wake_function+0x0/0xc > > [] worker_thread+0x0/0x136 > > [] kthread+0xb2/0xdc > > [] kthread+0x0/0xdc > > [] kernel_thread_helper+0x7/0x10 > > > > As for the last tracing, it looks to be valid bug to me. > > complete_change_console() should be called with the console sem > > taken. I'll look into this. > > If testing needed just ask please :) After grepping for change_console, all callers of change_console and complete_change_console are acquiring the console semaphore, so I really don't know what's going on here... Since you are using a non-vanilla kernel, can you just do a grep change_console of the kernel source and see if you can find a caller that missed doing an acquire_console_sem(). > > > BUG: at drivers/char/vt.c:3486 set_palette() > > [] set_palette+0x41/0x59 > > [] redraw_screen+0x110/0x17e > > [] complete_change_console+0x2a/0xba > > [] console_callback+0x45/0xbf > > [] run_workqueue+0x85/0x135 > > [] console_callback+0x0/0xbf > > [] worker_thread+0x10a/0x136 > > [] default_wake_function+0x0/0xc > > [] worker_thread+0x0/0x136 > > [] kthread+0xb2/0xdc > > [] kthread+0x0/0xdc > > [] kernel_thread_helper+0x7/0x10 > > > > Tony > > Cheers Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> >
> > Ah, my fault. Apply this patch on top.
>
> We're getting closer! The patch now works, and the dmesg has the following
> info:
Okay.
>
>
> ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> nvidiafb: Device ID: 10de0112
> fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be
> broken,
> fbmon: trying to fix monitor timings
> nvidiafb: EDID found from BUS2
>
> Display Information (EDID)
>
>EDID Version 1.3
>Manufacturer: SHP
>Model: 138e
>Serial#: 0
>Year: 1990 Week 0
>Display Characteristics:
> Monitor Operating Limits: From EDID
>H: 30-75KHz V: 60-60Hz DCLK: 170MHz
> Digital Display Input
> Sync:
> Max H-size in cm: 30
> Max V-size in cm: 23
> Gamma: 2.20
> DPMS: Active no, Suspend yes, Standby yes
> RGB Color Display
> Chroma
> RedX: 0.599 RedY: 0.335
> GreenX: 0.313 GreenY: 0.552
> BlueX:0.150 BlueY:0.145
> WhiteX: 0.313 WhiteY: 0.328
> First DETAILED Timing is preferred
>Detailed Timings
> 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
>
>Supported VESA Modes
> Manufacturer's mask: 0
>Standard Timings
> [EMAIL PROTECTED]
>
> nvidiafb: CRTC 1 is currently programmed for DFP
> nvidiafb: Using DFP on CRTC 1
> nvidiafb: Panel size is 1600 x 1200
> nvidiafb: Panel is TMDS
> nvidiafb: MTRR set to ON
> nvidiafb: Flat panel dithering disabled
> Console: switching to colour frame buffer device 200x75
> nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000)
>
>
>
>
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
>
Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work. You might want to change vfmin and vfmax to 59 and 61
respectively just to get leeway for mode calculation errors. This is in
drivers/video/fbmon.c, particularly b[5] and b[6] in this code:
case FBMON_FIX_TIMINGS:
printk("fbmon: trying to fix monitor timings\n");
b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (i = 0; i < 4; i++) {
if (!(edid_is_serial_block(b) ||
edid_is_ascii_block(b) ||
edid_is_monitor_block(b) ||
edid_is_timing_block(b))) {
b[0] = 0x00;
b[1] = 0x00;
b[2] = 0x00;
b[3] = 0xfd;
b[4] = 0x00;
b[5] = 60; /* vfmin */
b[6] = 60; /* vfmax */
b[7] = 30; /* hfmin */
b[8] = 75; /* hfmax */
b[9] = 17; /* pixclock - 170 MHz*/
b[10] = 0; /* GTF */
break;
}
b += DETAILED_TIMING_DESCRIPTION_SIZE;
}
Also try doing fbset 640x480-60, 800x600-60, 1024x768-60 and
1280x1024-60, and if they displayed correctly, we can add these modes to
your EDID block.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote: > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > However, I'm still getting the same snowy effects, which doesn't come > as a surprise since the actual mode timings used are just the same ... > BTW, you can also use CVT modes for nvidiafb, even if the mode in question is not present in the EDID block. For example: video=nvidiafb:[EMAIL PROTECTED] or [EMAIL PROTECTED] (The 'M' tells fb_find_mode to do a CVT calculation instead). If you use a reduced-blanking CVT mode, it might even reduce the snow of your DVI even at the highest resolution. So: video=nvidiafb:[EMAIL PROTECTED] (The additional 'R' will do reduced-blanking CVT calculation) Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote: > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote: > > > > > > However, I'm still getting the same snowy effects, which doesn't come > > > as a surprise since the actual mode timings used are just the same ... > > > > Yes, because the EDID has only 1 mode entry. But now you can use 'fbset > > 1024x768-60' (or any mode smaller than 1600x1200-60) for example and it > > should work. > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200, > and they /all/ come up snowy. This is starting to look queerer and > queerer. I've also tried changing vf min and max as you suggested: Before we proceed, do you agree that the patch will allow you to change video modes without disabling DDC support? So this is still a valid fix? > > > You might want to change vfmin and vfmax to 59 and 61 > > and even the M and MR methods which you suggested in the other email. > Since nvidiafb is being loaded from the command line because it's a > blacklisted module otherwise, I've been using the mode_option option. > However, neither the mode_option nor fbset seem to give me anything > not snowy. When does your display become snowy? Is the snow constant or does it only snow when doing heavy text operations, such as scrolling? I presume that X's nv driver or vesafb does not exhibit this problem? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 21:39 +0100, Luca Tettamanti wrote: > Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: > > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: > > Still scratching my head :| > > Tony, > this is the patch (modulo cosmetic stuff) that I sent to Giuseppe. I > believe it's correct (I cross checked with X.org driver): > Yes, the patch does look correct. I also don't understand why Giuseppe's hardware failed to do i2c with this... Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
> Hi Tony, Paul, Peter, fbdev, lkml, and mm,
>
> This is a first pass at abstracting deferred IO out from hecubafb and
> into fbdev as was discussed before:
> http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=117187443327466&w=2
>
> Please let me know your feedback and if it looks okay so far.
>
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
> +Another one may be if one has a device framebuffer that is in an usual
> format,
> +say diagonally shifting RGB, this may then be a mechanism for you to allow
> +apps to pretend to have a normal framebuffer but reswizzle for the device
> +framebuffer at vsync time based on the touched pagelist.
Hmm, yes, it can be used to implement a shadow framebuffer :-)
> +
> +How to use it: (for applications)
> +-
> +No changes needed. mmap the framebuffer like normal and just use it.
> +
> +How to use it: (for fbdev drivers)
> +--
> +The following example may be helpful.
> +
> +1. Setup your mmap and vm_ops structures. Eg:
> +
> +
> +The delay is the minimum delay between when the page_mkwrite trigger occurs
> +and when the deferred_io callback is called. The deferred_io callback is
> +explained below.
> +
> +static struct vm_operations_struct hecubafb_vm_ops = {
> + .nopage = hecubafb_vm_nopage,
> + .page_mkwrite = fb_deferred_io_mkwrite,
> +};
> +
It would seem to me that the above can be made generic, so we have this
instead:
static struct vm_operations_struct fb_deferred_vm_ops = {
.nopage = fb_deferred_io_vm_nopage,
.page_mkwrite = fb_deferred_io_mkwrite,
};
> +You will need a nopage routine to find and retrive the struct page for your
> +framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
> +Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
> +
> +static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> + vma->vm_ops = &hecubafb_vm_ops;
> + vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
> + vma->vm_private_data = info;
> + return 0;
> +}
And this too as fb_deferred_io_mmap.
> +
> +static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
> + unsigned long vaddr, int *type)
> +{
> + unsigned long offset;
> + struct page *page;
> + struct fb_info *info = vma->vm_private_data;
> +
> + offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
> + if (offset >= (DPY_W*DPY_H)/8)
> + return NOPAGE_SIGBUS;
> +
To make it generic, this can simply be:
if (offset >= info->fix.smem_len)
return NOPAGE_SIGBUS.
> + page = vmalloc_to_page(info->screen_base + offset);
> + if (!page)
> + return NOPAGE_OOM;
> +
> + get_page(page);
> + if (type)
> + *type = VM_FAULT_MINOR;
> + return page;
> +}
> +
>
> +static struct fb_deferred_io hecubafb_defio = {
> + .delay = HZ,
> + .deferred_io= hecubafb_dpy_deferred_io,
> +};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 2822526..863126a 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1325,6 +1325,7 @@ register_framebuffer(struct fb_info *fb_info)
>
> event.info = fb_info;
> fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> + fb_deferred_io_init(fb_info);
> return 0;
> }
>
> @@ -1355,6 +1356,7 @@ unregister_framebuffer(struct fb_info *fb_info)
> fb_destroy_modelist(&fb_info->modelist);
> registered_fb[i]=NULL;
> num_registered_fb--;
> + fb_deferred_io_cleanup(fb_info);
> fb_cleanup_device(fb_info);
> device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> event.info = fb_info;
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
> +static void hecubafb_dpy_update(struct hecubafb_par *par)
> +{
> + int i;
> + unsigned char *buf = par->info->screen_base;
> +
> + apollo_send_command(par, 0xA0);
> +
> + for (i=0; i < (DPY_W*DPY_H/8); i++) {
> + apollo_send_data(par, *(buf++));
> + }
> +
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Is there a way to selectively update only the touched pages, ie from the
fbdevio->pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this lis
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote: > On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote: > > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200, > > > and they /all/ come up snowy. This is starting to look queerer and > > > queerer. I've also tried changing vf min and max as you suggested: > > > > Before we proceed, do you agree that the patch will allow you to change > > video modes without disabling DDC support? So this is still a valid > > fix? > > You're right, I hadn't realized that. I can now access all the sizes > from 640 to 1600, so I would say the fix is valid. Okay, thanks. > > > When does your display become snowy? Is the snow constant or does it > > only snow when doing heavy text operations, such as scrolling? > > The snowy is constant and abundant, and it seems to be independent of > video size (640 through 1600) and screen occupation (single prompt > line to fullscreen mc session) and usage. > > > I presume that X's nv driver or vesafb does not exhibit this problem? > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for > this reason), then the screen is very snowy with X's nv too. > Hmm..., I really don't know how to fix this except to look at Xorg's code and look for a difference. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-23 at 13:45 +0100, Ondrej Zajicek wrote: > On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote: > > On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote: > > > This patch adds driver for S3 Trio / S3 Virge. Driver is tested > > > with most versions of S3 Trio and S3 Virge, on i386. > > > It is tested both as compiled-in and module. It is against > > > linux-2.6.20 . > > > > > > This is version 3. There are some minor modifications from version 2 > > > (mostly coding style cleanups). > > > > Nice, the first driver to use tileblit :-) > > > > Since this driver is already in the -mm tree, can you resubmit a diff > > against that? > > This driver was removed from -mm tree, because it is in 2.6.21-rc1 . > So it is probably unnnecessary to resubmit a diff, isn't it? > Okay, I thought the one in the tree was an older version. Thanks for clarifying. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through 1600) and screen occupation (single prompt
> > > line to fullscreen mc session) and usage.
> > >
> > > > I presume that X's nv driver or vesafb does not exhibit this problem?
> > >
> > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > > this reason), then the screen is very snowy with X's nv too.
> > >
> >
> > Hmm..., I really don't know how to fix this except to look at Xorg's
> > code and look for a difference.
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Tony
nvidiafb: Bring back generic ddc reading
Make nvidiafb use fb_ddc_read(). This patch was submitted before but was
reverted due to problems in a non-x86 platform. This includes a fix for that
where ddc reading is bypassed if there is no DDC bus (duh).
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
drivers/video/nvidia/nv_i2c.c | 44 ++---
1 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..b91d404 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data
if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
val = 1;
- val = VGA_RD08(par->PCIO, 0x3d5);
-
return val;
}
@@ -159,51 +157,13 @@ void nvidia_delete_i2c_busses(struct nvi
}
-static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
-{
- u8 start = 0x0;
- struct i2c_msg msgs[] = {
- {
-.addr = 0x50,
-.len = 1,
-.buf = &start,
-}, {
-.addr = 0x50,
-.flags = I2C_M_RD,
-.len = EDID_LENGTH,
-},
- };
- u8 *buf;
-
- if (!chan->par)
- return NULL;
-
- buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!buf) {
- dev_warn(&chan->par->pci_dev->dev, "Out of memory!\n");
- return NULL;
- }
- msgs[1].buf = buf;
-
- if (i2c_transfer(&chan->adapter, msgs, 2) == 2)
- return buf;
- dev_dbg(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
- kfree(buf);
- return NULL;
-}
-
int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
{
struct nvidia_par *par = info->par;
u8 *edid = NULL;
- int i;
- for (i = 0; i < 3; i++) {
- /* Do the real work */
- edid = nvidia_do_probe_i2c_edid(&par->chan[conn - 1]);
- if (edid)
- break;
- }
+ if (par->chan[conn - 1].par)
+ edid = fb_ddc_read(&par->chan[conn - 1].adapter);
if (!edid && conn == 1) {
/* try to get from firmware */
Re: 2.6.21-rc1: framebuffer/console boot failure
On Sat, 2007-02-24 at 23:00 +, Andrew Nelless wrote:
> On Sat, February 24, 2007 11:09 am, Andrew Morton wrote:
> >
> > Presumably this regression was caused by the ACPI merge. Are you able to
> > capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be
> > useful here, thanks.
> >
>
> I've confirmed a few things:
>
> 1) 2.6.21-rc1 actually will boot intermittently.
> 2) pci=noacpi always allows 2.6.21-rc1 to boot.
> 2) 2.6.20 always boots.
> 3) There doesn't seem to be a pattern (that I can tell) between booting and
> not booting,
> although it'll now boot more often than not (It seemed very much t'other way
> around yesterday)
> 4) When 2.6.21-rc1 doesn't boot ('Boot'? Am i using the right term here?
> hmm...) nothing is
> sent across netconsole at all.
> 5) Netconsole is useful.
>
> I've uploaded all the dmesg output i've managed to capture here:
> http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/
>
> > (You get added to the post-2.6.20 regression list, so you'll be hearing
> > from us quite a lot for the next month. Sorry ;))
> >
>
> Lucky me :)
How about booting with just vga=normal?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote: > On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote: > > > > > > Keep in mind that setting nvidiafb to totally ignore the EDID (either > > > by not compiling in EDID support or by using e.g. the ignoreedid patch > > > I had proposed) the snow effect is extremely reduced, > > > > I did not know that, just scanned the entire thread. Try this patch, it > > makes use of fb_ddc_read*() which I believe has extra steps to prevent > > display corruption. It also incorporates Luca's i2c fix. > > Applied. No noticeable difference, in the sense that the EDID debug > output is still the same and so is the snow effect. > Here's a temporary workaround: In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment this out: if (par->chan[conn - 1].par) edid = fb_ddc_read(&par->chan[conn - 1].adapter); and make sure CONFIG_FIRMWARE_EDID=y. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote: > On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote: > > > > > > Applied. No noticeable difference, in the sense that the EDID debug > > > output is still the same and so is the snow effect. > > > > Here's a temporary workaround: > > > > In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment > > this out: > > > > if (par->chan[conn - 1].par) > > edid = fb_ddc_read(&par->chan[conn - 1].adapter); > > > > and make sure CONFIG_FIRMWARE_EDID=y. > > With this patch, I don't get any dmesg info about my monitor EDID, but > I still get the snow. Could it be that there's something else on my > system which is setting the video to some absurd timings when I > switchg on the framebuffer console? I'm running an up-to-date debian > unstable. > At this point, I don't know. You're the first person to report this kind of problem. I'm still studying the nvidiafb and Xorg source code. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx framebuffer garbles display in 2.6.19.5
On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote: > Hi all :) > > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot > test in 2.6.20.x because it doesn't compile, the infamous BDF negative > offset problem) garbles the display, leaving only a lot of thin lines, > just like sync was lost. The display can be repaired by switching to > another console, but this is annoying. This happens with a Voodoo 3 > 3000, using [EMAIL PROTECTED] mode. > > Anyone has this problem? Can it be solved changing anything? > > Raúl Núñez de Arenas Coronado Try fbset -a -vyres 600 first and let us know of the result. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] 2.6.21-rc1 dims my LCD
On Mon, 2007-02-26 at 15:43 +, Richard Purdie wrote: > On Mon, 2007-02-26 at 16:24 +0100, Jiri Kosina wrote: > > On Mon, 26 Feb 2007, Richard Purdie wrote: > > > > > Jiri: I've appended a patch that should already be queued, could you > > > test and see if it solves the problem. > > > > Thanks. In the meantime I have gone through the code and I can confirm > > that this is the root cause of what I am observing. > > > > Now regarding the patch - at the time when the dim happened previously, > > currently there is a observable blink (after which the brightness is > > correct). > > The reason for the behaviour is that its turning the backlight down/off > to save power as it thinks the screen is blank. The blink therefore > makes sense as far as the backlight class is concerned and its working > as intended now. > > > I have put some debugging printk() into fb_notifier_callback(), > > and it turns out that on FB_EVENT_CONBLANK, there are two successive calls > > to backlight_update_status(), second immediately following the first one: > > > > Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with > > bd->props.fb_blank == 1, bd->props.brightness == 0 > > Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with > > bd->props.fb_blank == 0, bd->props.brightness == 0 > > > > Is this really a right thing to do? Well, no, the console should not blank and immediately unblank. Of course, the console can blank after some time and can be induced to unblank after a keyboard event, for example. Besides the debugging printk's, can you also add something like WARN_ON(1); so you can get a tracing too. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tdfx framebuffer garbles display in 2.6.19.5
On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote: > Hi Antonino :) > > * Antonino A. Daplas <[EMAIL PROTECTED]> dixit: > > On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote: > > > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot > > > test in 2.6.20.x because it doesn't compile, the infamous BDF negative > > > offset problem) garbles the display, leaving only a lot of thin lines, > > > just like sync was lost. The display can be repaired by switching to > > > another console, but this is annoying. This happens with a Voodoo 3 > > > 3000, using [EMAIL PROTECTED] mode. > > > > Try fbset -a -vyres 600 first and let us know of the result. > > After doing this, I no longer can garble the display (before, just a > "ls -lR /" was enough to do it, in fact, any big output garbled the > display). The only problem with this solution is that the scroll speed > has decreased a bit. In fact, the scroll speed is affected by the vyres > parameter a lot! The highter the vyres, the faster the scroll, and I > cannot reproduce the problem anymore after changing it once! Display panning is what makes scrolling fast which is the default scroll method if vyres > yres. Unfortunately, tdfxfb occasionally have problems with this method, the higher the vyres, the greater the likelihood of screen corruption. That's why tdfxb limits the vyres to a maximum of 4096. As to why the problem disappeared just by changing this parameter, that I too don't know. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
