[PATCH] fbdev: make the best-fit section of fb_find_mode return the closest matching mode
From: Michal Januszewski <[EMAIL PROTECTED]>
Currently, if a perfect match in terms of resolution is not found,
fb_find_mode() only looks for a best-fit mode among modes with a
higher resolution than the one requested. Thus, if the user
requests a resolution higher than the largest supported one, they
are dropped to the default mode (usually a low resolution one).
Change this behaviour so that all valid video modes are considered
when looking for a best-fit mode, while still preferring modes
with a higher resolution.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 08d0725..0b6a45f 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -522,7 +522,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
- u32 best, diff;
+ u32 best, diff, tdiff;
for (i = namelen-1; i >= 0; i--) {
switch (name[i]) {
@@ -651,19 +651,27 @@ done:
return (refresh_specified) ? 2 : 1;
}
- diff = xres + yres;
+ diff = 2 * (xres + yres);
best = -1;
DPRINTK("Trying best-fit modes\n");
for (i = 0; i < dbsize; i++) {
- if (xres <= db[i].xres && yres <= db[i].yres) {
DPRINTK("Trying %ix%i\n", db[i].xres, db[i].yres);
if (!fb_try_mode(var, info, [i], bpp)) {
- if (diff > (db[i].xres - xres) + (db[i].yres - yres)) {
- diff = (db[i].xres - xres) + (db[i].yres - yres);
- best = i;
- }
+ tdiff = abs(db[i].xres - xres) +
+ abs(db[i].yres - yres);
+
+ /*
+* Penalize modes with resolutions smaller
+* than requested.
+*/
+ if (xres > db[i].xres || yres > db[i].yres)
+ tdiff += xres + yres;
+
+ if (diff > tdiff) {
+ diff = tdiff;
+ best = i;
+ }
}
- }
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
--
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/
[PATCH] fbdev: make the best-fit section of fb_find_mode return the closest matching mode
From: Michal Januszewski [EMAIL PROTECTED]
Currently, if a perfect match in terms of resolution is not found,
fb_find_mode() only looks for a best-fit mode among modes with a
higher resolution than the one requested. Thus, if the user
requests a resolution higher than the largest supported one, they
are dropped to the default mode (usually a low resolution one).
Change this behaviour so that all valid video modes are considered
when looking for a best-fit mode, while still preferring modes
with a higher resolution.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 08d0725..0b6a45f 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -522,7 +522,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
- u32 best, diff;
+ u32 best, diff, tdiff;
for (i = namelen-1; i = 0; i--) {
switch (name[i]) {
@@ -651,19 +651,27 @@ done:
return (refresh_specified) ? 2 : 1;
}
- diff = xres + yres;
+ diff = 2 * (xres + yres);
best = -1;
DPRINTK(Trying best-fit modes\n);
for (i = 0; i dbsize; i++) {
- if (xres = db[i].xres yres = db[i].yres) {
DPRINTK(Trying %ix%i\n, db[i].xres, db[i].yres);
if (!fb_try_mode(var, info, db[i], bpp)) {
- if (diff (db[i].xres - xres) + (db[i].yres - yres)) {
- diff = (db[i].xres - xres) + (db[i].yres - yres);
- best = i;
- }
+ tdiff = abs(db[i].xres - xres) +
+ abs(db[i].yres - yres);
+
+ /*
+* Penalize modes with resolutions smaller
+* than requested.
+*/
+ if (xres db[i].xres || yres db[i].yres)
+ tdiff += xres + yres;
+
+ if (diff tdiff) {
+ diff = tdiff;
+ best = i;
+ }
}
- }
}
if (best != -1) {
fb_try_mode(var, info, db[best], bpp);
--
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/
[PATCH] uvesafb: don't treat valid modes returned by fb_find_mode() as errors
From: Michal Januszewski <[EMAIL PROTECTED]>
Don't treat valid modes returned by fb_find_mode() (best-fit modes,
default modes or the first valid mode) as errors.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index a14ef89..fc68b3e 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -885,7 +885,7 @@ static int __devinit uvesafb_vbe_init_mode(struct fb_info
*info)
}
/* fb_find_mode() failed */
- if (i == 0 || i >= 3) {
+ if (i == 0) {
info->var.xres = 640;
info->var.yres = 480;
mode = (struct fb_videomode *)
--
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/
[PATCH] fbdev: make the best-fit section of fb_find_mode return the closest matching mode
From: Michal Januszewski <[EMAIL PROTECTED]>
Currently, if a perfect match in terms of resolution is not found,
fb_find_mode() only looks for a best-fit mode among modes with a
higher resolution than the one requested. Thus, if the user
requests a resolution higher than the largest supported one, they
are dropped to the default mode (usually a low resolution one).
Change this behaviour so that the true closest match in terms
of the city-block metric is returned.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 08d0725..bc29ef3 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -655,15 +655,15 @@ done:
best = -1;
DPRINTK("Trying best-fit modes\n");
for (i = 0; i < dbsize; i++) {
- if (xres <= db[i].xres && yres <= db[i].yres) {
DPRINTK("Trying %ix%i\n", db[i].xres, db[i].yres);
if (!fb_try_mode(var, info, [i], bpp)) {
- if (diff > (db[i].xres - xres) + (db[i].yres - yres)) {
- diff = (db[i].xres - xres) + (db[i].yres - yres);
- best = i;
- }
+ if (diff > abs(db[i].xres - xres) +
+ abs(db[i].yres - yres)) {
+ diff = abs(db[i].xres - xres) +
+ abs(db[i].yres - yres);
+ best = i;
+ }
}
- }
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
--
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/
[PATCH] fbdev: make the best-fit section of fb_find_mode return the closest matching mode
From: Michal Januszewski [EMAIL PROTECTED]
Currently, if a perfect match in terms of resolution is not found,
fb_find_mode() only looks for a best-fit mode among modes with a
higher resolution than the one requested. Thus, if the user
requests a resolution higher than the largest supported one, they
are dropped to the default mode (usually a low resolution one).
Change this behaviour so that the true closest match in terms
of the city-block metric is returned.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 08d0725..bc29ef3 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -655,15 +655,15 @@ done:
best = -1;
DPRINTK(Trying best-fit modes\n);
for (i = 0; i dbsize; i++) {
- if (xres = db[i].xres yres = db[i].yres) {
DPRINTK(Trying %ix%i\n, db[i].xres, db[i].yres);
if (!fb_try_mode(var, info, db[i], bpp)) {
- if (diff (db[i].xres - xres) + (db[i].yres - yres)) {
- diff = (db[i].xres - xres) + (db[i].yres - yres);
- best = i;
- }
+ if (diff abs(db[i].xres - xres) +
+ abs(db[i].yres - yres)) {
+ diff = abs(db[i].xres - xres) +
+ abs(db[i].yres - yres);
+ best = i;
+ }
}
- }
}
if (best != -1) {
fb_try_mode(var, info, db[best], bpp);
--
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/
[PATCH] uvesafb: don't treat valid modes returned by fb_find_mode() as errors
From: Michal Januszewski [EMAIL PROTECTED]
Don't treat valid modes returned by fb_find_mode() (best-fit modes,
default modes or the first valid mode) as errors.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index a14ef89..fc68b3e 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -885,7 +885,7 @@ static int __devinit uvesafb_vbe_init_mode(struct fb_info
*info)
}
/* fb_find_mode() failed */
- if (i == 0 || i = 3) {
+ if (i == 0) {
info-var.xres = 640;
info-var.yres = 480;
mode = (struct fb_videomode *)
--
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/
[PATCH] Fix a spurious kfree_skb() call
Remove a spurious call to kfree_skb() in the connector rx_skb handler.
This fixes a regression introduced by the '[NET]: make netlink user ->
kernel interface synchronious' patch (cd40b7d3983c708aabe3d3008ec64ffce56d33b0)
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 0e328d3..6883fcb 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -218,7 +218,7 @@ static void cn_rx_skb(struct sk_buff *__skb)
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
kfree_skb(skb);
- goto out;
+ return;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -229,9 +229,6 @@ static void cn_rx_skb(struct sk_buff *__skb)
if (err < 0)
kfree_skb(skb);
}
-
-out:
- kfree_skb(__skb);
}
/*
-
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/
[PATCH] Fix a spurious kfree_skb() call
Remove a spurious call to kfree_skb() in the connector rx_skb handler.
This fixes a regression introduced by the '[NET]: make netlink user -
kernel interface synchronious' patch (cd40b7d3983c708aabe3d3008ec64ffce56d33b0)
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 0e328d3..6883fcb 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -218,7 +218,7 @@ static void cn_rx_skb(struct sk_buff *__skb)
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
kfree_skb(skb);
- goto out;
+ return;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -229,9 +229,6 @@ static void cn_rx_skb(struct sk_buff *__skb)
if (err 0)
kfree_skb(skb);
}
-
-out:
- kfree_skb(__skb);
}
/*
-
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/
[PATCH -mm] uvesafb: Don't access VGA registers directly when running on non-x86
The VGA registers are only available at their legacy IO locations on
x86. Don't try to access them when running on other arches.
Note that the code accessing them directly is just an optimization
(limits slow BIOS function calls). We don't lose any functionality
by using BIOS calls instead of it on non-x86.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 853323e..b983d26 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -19,8 +19,10 @@
#include
#include
#include
-#include
#include
+#ifdef CONFIG_X86
+#include
+#endif
#ifdef CONFIG_MTRR
#include
#endif
@@ -935,6 +937,7 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
if (start + count > 256)
return -EINVAL;
+#ifdef CONFIG_X86
/* Use VGA registers if mode is VGA-compatible. */
if (i >= 0 && i < par->vbe_modes_cnt &&
par->vbe_modes[i].mode_attr & VBE_MODE_VGACOMPAT) {
@@ -957,8 +960,10 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
"D" (entries),/* EDI */
"S" (>pmi_pal)); /* ESI */
}
-#endif
- else {
+#endif /* CONFIG_X86_32 */
+ else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
@@ -1102,6 +1107,7 @@ static int uvesafb_blank(int blank, struct fb_info *info)
struct uvesafb_ktask *task;
int err = 1;
+#ifdef CONFIG_X86
if (par->vbe_ib.capabilities & VBE_CAP_VGACOMPAT) {
int loop = 1;
u8 seq = 0, crtc17 = 0;
@@ -1124,7 +1130,9 @@ static int uvesafb_blank(int blank, struct fb_info *info)
while (loop--);
vga_wcrt(NULL, 0x17, crtc17);
vga_wseq(NULL, 0x00, 0x03);
- } else {
+ } else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
-
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/
[PATCH -mm] uvesafb: Don't access VGA registers directly when running on non-x86
The VGA registers are only available at their legacy IO locations on
x86. Don't try to access them when running on other arches.
Note that the code accessing them directly is just an optimization
(limits slow BIOS function calls). We don't lose any functionality
by using BIOS calls instead of it on non-x86.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 853323e..b983d26 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -19,8 +19,10 @@
#include linux/io.h
#include linux/mutex.h
#include video/edid.h
-#include video/vga.h
#include video/uvesafb.h
+#ifdef CONFIG_X86
+#include video/vga.h
+#endif
#ifdef CONFIG_MTRR
#include asm/mtrr.h
#endif
@@ -935,6 +937,7 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
if (start + count 256)
return -EINVAL;
+#ifdef CONFIG_X86
/* Use VGA registers if mode is VGA-compatible. */
if (i = 0 i par-vbe_modes_cnt
par-vbe_modes[i].mode_attr VBE_MODE_VGACOMPAT) {
@@ -957,8 +960,10 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
D (entries),/* EDI */
S (par-pmi_pal)); /* ESI */
}
-#endif
- else {
+#endif /* CONFIG_X86_32 */
+ else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
@@ -1102,6 +1107,7 @@ static int uvesafb_blank(int blank, struct fb_info *info)
struct uvesafb_ktask *task;
int err = 1;
+#ifdef CONFIG_X86
if (par-vbe_ib.capabilities VBE_CAP_VGACOMPAT) {
int loop = 1;
u8 seq = 0, crtc17 = 0;
@@ -1124,7 +1130,9 @@ static int uvesafb_blank(int blank, struct fb_info *info)
while (loop--);
vga_wcrt(NULL, 0x17, crtc17);
vga_wseq(NULL, 0x00, 0x03);
- } else {
+ } else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
-
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/
[PATCH -mm] uvesafb: Don't access VGA registers directly when running on non-x86
The VGA registers are only available at their legacy IO locations on x86.
Don't try to access them when running on other arches.
Note that the code accessing them directly is just an optimization (limits
slow BIOS function calls). We don't lose any functionality by using
BIOS calls instead of it on non-x86.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 853323e..74fa7c7 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -935,6 +935,7 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
if (start + count > 256)
return -EINVAL;
+#ifdef CONFIG_X86
/* Use VGA registers if mode is VGA-compatible. */
if (i >= 0 && i < par->vbe_modes_cnt &&
par->vbe_modes[i].mode_attr & VBE_MODE_VGACOMPAT) {
@@ -957,8 +958,10 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
"D" (entries),/* EDI */
"S" (>pmi_pal)); /* ESI */
}
-#endif
- else {
+#endif /* CONFIG_X86_32 */
+ else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
@@ -1102,6 +1105,7 @@ static int uvesafb_blank(int blank, struct fb_info *info)
struct uvesafb_ktask *task;
int err = 1;
+#ifdef CONFIG_X86
if (par->vbe_ib.capabilities & VBE_CAP_VGACOMPAT) {
int loop = 1;
u8 seq = 0, crtc17 = 0;
@@ -1124,7 +1128,9 @@ static int uvesafb_blank(int blank, struct fb_info *info)
while (loop--);
vga_wcrt(NULL, 0x17, crtc17);
vga_wseq(NULL, 0x00, 0x03);
- } else {
+ } else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
-
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 -mm] video: uvesafb: Add X86 dependency.
On Tue, Sep 11, 2007 at 09:31:59PM +0900, Paul Mundt wrote: > > Anyway, I think it is up to Michal to decide if we should remove the > > kernel support for other archs, or let it stay a bit more while working > > on solving the v86d side of things. So I'll just step aside now > > > Once v86d is fixed up to get at the ROM directly and the driver uses MMIO > directly, I don't see a problem with unrestricting it. For the time being > however, the build is both broken, and the emulator it uses won't run on > anything but x86, so I see no reason not to add a Kconfig dependency that > reflects this until such a time where it's no longer true. > > At least if there's a set of restrictions on something fairly generic, > they tend to be visible, and they also tend to get fixed up over time. We > should however not enable something generically which at the moment is > very much tied to a single platform. Later patches can remove the > dependency at such a time that that assertion no longer holds true. Just to clear things up: yes, at the moment v86d supports only x86 and amd64 (aka x86_64) and yes, supporting other arches is possible and planned. The main limiting factors as far as this is concerned are the little amount of my free time and the fact that I don't currently have access to non-x86 hardware. Please note that the kernel part (i.e. uvesafb) is meant to be generic (it currently uses VGA IO ports on non-x86, which is a bug and for which a patch will follow) and support or lack thereof for a specific arch should be dependent on v86d only. That being said, I think that having a kernel dependency tracking the development status of userspace code is generally a bad idea. Best regards, -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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 -mm] video: uvesafb: Add X86 dependency.
On Tue, Sep 11, 2007 at 09:31:59PM +0900, Paul Mundt wrote: Anyway, I think it is up to Michal to decide if we should remove the kernel support for other archs, or let it stay a bit more while working on solving the v86d side of things. So I'll just step aside now Once v86d is fixed up to get at the ROM directly and the driver uses MMIO directly, I don't see a problem with unrestricting it. For the time being however, the build is both broken, and the emulator it uses won't run on anything but x86, so I see no reason not to add a Kconfig dependency that reflects this until such a time where it's no longer true. At least if there's a set of restrictions on something fairly generic, they tend to be visible, and they also tend to get fixed up over time. We should however not enable something generically which at the moment is very much tied to a single platform. Later patches can remove the dependency at such a time that that assertion no longer holds true. Just to clear things up: yes, at the moment v86d supports only x86 and amd64 (aka x86_64) and yes, supporting other arches is possible and planned. The main limiting factors as far as this is concerned are the little amount of my free time and the fact that I don't currently have access to non-x86 hardware. Please note that the kernel part (i.e. uvesafb) is meant to be generic (it currently uses VGA IO ports on non-x86, which is a bug and for which a patch will follow) and support or lack thereof for a specific arch should be dependent on v86d only. That being said, I think that having a kernel dependency tracking the development status of userspace code is generally a bad idea. Best regards, -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH -mm] uvesafb: Don't access VGA registers directly when running on non-x86
The VGA registers are only available at their legacy IO locations on x86.
Don't try to access them when running on other arches.
Note that the code accessing them directly is just an optimization (limits
slow BIOS function calls). We don't lose any functionality by using
BIOS calls instead of it on non-x86.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 853323e..74fa7c7 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -935,6 +935,7 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
if (start + count 256)
return -EINVAL;
+#ifdef CONFIG_X86
/* Use VGA registers if mode is VGA-compatible. */
if (i = 0 i par-vbe_modes_cnt
par-vbe_modes[i].mode_attr VBE_MODE_VGACOMPAT) {
@@ -957,8 +958,10 @@ static int uvesafb_setpalette(struct uvesafb_pal_entry
*entries, int count,
D (entries),/* EDI */
S (par-pmi_pal)); /* ESI */
}
-#endif
- else {
+#endif /* CONFIG_X86_32 */
+ else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
@@ -1102,6 +1105,7 @@ static int uvesafb_blank(int blank, struct fb_info *info)
struct uvesafb_ktask *task;
int err = 1;
+#ifdef CONFIG_X86
if (par-vbe_ib.capabilities VBE_CAP_VGACOMPAT) {
int loop = 1;
u8 seq = 0, crtc17 = 0;
@@ -1124,7 +1128,9 @@ static int uvesafb_blank(int blank, struct fb_info *info)
while (loop--);
vga_wcrt(NULL, 0x17, crtc17);
vga_wseq(NULL, 0x00, 0x03);
- } else {
+ } else
+#endif /* CONFIG_X86 */
+ {
task = uvesafb_prep();
if (!task)
return -ENOMEM;
-
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/
[PATCH] fbdev: find mode with the highest/safest refresh rate in fb_find_mode()
Currently, if the refresh rate is not specified, fb_find_mode() returns
the first known video mode with the requested resolution, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned when the driver provides a custom
video mode database and the monitor limits, and a mode with the safe
60 Hz refresh rate otherwise.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..9598c46 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,26 +606,43 @@ done:
DPRINTK("Trying specified video mode%s %ix%i\n",
refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
- diff = refresh;
+ if (!refresh_specified) {
+ /*
+* If the caller has provided a custom mode database and a
+* valid monspecs structure, we look for the mode with the
+* highest refresh rate. Otherwise we play it safe it and
+* try to find a mode with a refresh rate closest to the
+* standard 60 Hz.
+*/
+ if (db != modedb &&
+ info->monspecs.vfmin && info->monspecs.vfmax &&
+ info->monspecs.hfmin && info->monspecs.hfmax &&
+ info->monspecs.dclkmax) {
+ refresh = 1000;
+ } else {
+ refresh = 60;
+ }
+ }
+
+ diff = -1;
best = -1;
for (i = 0; i < dbsize; i++) {
- if (name_matches(db[i], name, namelen) ||
- (res_specified && res_matches(db[i], xres, yres))) {
- if(!fb_try_mode(var, info, [i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
- return 1;
- else {
- if(diff > abs(db[i].refresh - refresh))
{
- diff = abs(db[i].refresh -
refresh);
- best = i;
- }
+ if ((name_matches(db[i], name, namelen) ||
+ (res_specified && res_matches(db[i], xres, yres))) &&
+ !fb_try_mode(var, info, [i], bpp)) {
+ if (refresh_specified && db[i].refresh == refresh) {
+ return 1;
+ } else {
+ if (abs(db[i].refresh - refresh) < diff) {
+ diff = abs(db[i].refresh - refresh);
+ best = i;
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
diff = xres + yres;
-
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/
[PATCH] fbdev: find mode with the highest/safest refresh rate in fb_find_mode()
Currently, if the refresh rate is not specified, fb_find_mode() returns
the first known video mode with the requested resolution, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned when the driver provides a custom
video mode database and the monitor limits, and a mode with the safe
60 Hz refresh rate otherwise.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..9598c46 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,26 +606,43 @@ done:
DPRINTK(Trying specified video mode%s %ix%i\n,
refresh_specified ? : (ignoring refresh rate), xres, yres);
- diff = refresh;
+ if (!refresh_specified) {
+ /*
+* If the caller has provided a custom mode database and a
+* valid monspecs structure, we look for the mode with the
+* highest refresh rate. Otherwise we play it safe it and
+* try to find a mode with a refresh rate closest to the
+* standard 60 Hz.
+*/
+ if (db != modedb
+ info-monspecs.vfmin info-monspecs.vfmax
+ info-monspecs.hfmin info-monspecs.hfmax
+ info-monspecs.dclkmax) {
+ refresh = 1000;
+ } else {
+ refresh = 60;
+ }
+ }
+
+ diff = -1;
best = -1;
for (i = 0; i dbsize; i++) {
- if (name_matches(db[i], name, namelen) ||
- (res_specified res_matches(db[i], xres, yres))) {
- if(!fb_try_mode(var, info, db[i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
- return 1;
- else {
- if(diff abs(db[i].refresh - refresh))
{
- diff = abs(db[i].refresh -
refresh);
- best = i;
- }
+ if ((name_matches(db[i], name, namelen) ||
+ (res_specified res_matches(db[i], xres, yres)))
+ !fb_try_mode(var, info, db[i], bpp)) {
+ if (refresh_specified db[i].refresh == refresh) {
+ return 1;
+ } else {
+ if (abs(db[i].refresh - refresh) diff) {
+ diff = abs(db[i].refresh - refresh);
+ best = i;
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, db[best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
diff = xres + yres;
-
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] fbdev: find mode with highest refresh rate in fb_find_mode()
On Wed, Jul 18, 2007 at 11:18:15PM +0800, Antonino A. Daplas wrote:
> > > Currently if the refresh rate is not specified fb_find_mode() returns
> > > the first known video mode with the requested resoluion, which provides
> > > no guarantees wrt the refresh rate. Change this so that the mode with
> > > the highest refresh rate is returned instead.
> >
> > What refresh rate it sets when used on card or monitor without DDC?
>
> Yes, I noted this also while reviewing patches. fb_find_mode() is used
> predominantly with the 'generic' modedb which contains modes that are
> not specific to the card or monitor. And fb_try_mode() is not a
> guarantee that the returned refresh rate will be safe (we have a lot of
> drivers that do not check the timings against the display capabilities).
>
> It would be best that fb_find_mode() return the safest refresh rate
> (60Hz) instead of the highest.
How about modifying it so that it looks for a mode with the highest
refresh rate if either a non-generic modedb is used or
info.monspecs.{vfmin,vfmax,hfmin,hfmax,dclkmax} are all non-zero,
and for a mode with refresh rate closest to 60 Hz otherwise?
I'm sorry for the delayed reply.
Best regards.
--
Michal Januszewski JID: [EMAIL PROTECTED]
Gentoo Linux Developerhttp://people.gentoo.org/spock
-
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] uvesafb: select connector in Kconfig
On Sat, Aug 25, 2007 at 08:23:41AM -0700, Randy Dunlap wrote: > There are 2 problems with this. > > a. CONNECTOR depends on NET, but select won't enable NET, so if > NET is not enabled otherwise, CONNECTOR still won't build. > This is a longstanding select/kconfig issue. > > b. CONNECTOR depends on NET, so if select did follow the depends > chain and enable NET, it would be enabling the networking subsystem, > which is something that should not be done quietly. > > select should only be used for enabling small library-like code > (if even then). Avoid it whenever possible. OK, thanks for pointing this out. Let's keep the original dependency on CONNECTOR then. Best regards, Michal - 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] uvesafb: select connector in Kconfig
On Sat, Aug 25, 2007 at 08:23:41AM -0700, Randy Dunlap wrote: There are 2 problems with this. a. CONNECTOR depends on NET, but select won't enable NET, so if NET is not enabled otherwise, CONNECTOR still won't build. This is a longstanding select/kconfig issue. b. CONNECTOR depends on NET, so if select did follow the depends chain and enable NET, it would be enabling the networking subsystem, which is something that should not be done quietly. select should only be used for enabling small library-like code (if even then). Avoid it whenever possible. OK, thanks for pointing this out. Let's keep the original dependency on CONNECTOR then. Best regards, Michal - 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] fbdev: find mode with highest refresh rate in fb_find_mode()
On Wed, Jul 18, 2007 at 11:18:15PM +0800, Antonino A. Daplas wrote:
Currently if the refresh rate is not specified fb_find_mode() returns
the first known video mode with the requested resoluion, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned instead.
What refresh rate it sets when used on card or monitor without DDC?
Yes, I noted this also while reviewing patches. fb_find_mode() is used
predominantly with the 'generic' modedb which contains modes that are
not specific to the card or monitor. And fb_try_mode() is not a
guarantee that the returned refresh rate will be safe (we have a lot of
drivers that do not check the timings against the display capabilities).
It would be best that fb_find_mode() return the safest refresh rate
(60Hz) instead of the highest.
How about modifying it so that it looks for a mode with the highest
refresh rate if either a non-generic modedb is used or
info.monspecs.{vfmin,vfmax,hfmin,hfmax,dclkmax} are all non-zero,
and for a mode with refresh rate closest to 60 Hz otherwise?
I'm sorry for the delayed reply.
Best regards.
--
Michal Januszewski JID: [EMAIL PROTECTED]
Gentoo Linux Developerhttp://people.gentoo.org/spock
-
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/
[PATCH] uvesafb: select connector in Kconfig
Make uvesafb select connector instead of depending on it being already selected. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index f1cc899..e152eed 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -594,7 +594,8 @@ config FB_TGA config FB_UVESA tristate "Userspace VESA VGA graphics support" - depends on FB && CONNECTOR + depends on FB + select CONNECTOR select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - 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/
[PATCH] uvesafb: select connector in Kconfig
Make uvesafb select connector instead of depending on it being already selected. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index f1cc899..e152eed 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -594,7 +594,8 @@ config FB_TGA config FB_UVESA tristate Userspace VESA VGA graphics support - depends on FB CONNECTOR + depends on FB + select CONNECTOR select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - 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/
[PATCH 6/7] uvesafb: use the default refresh rate if the monitor limits are not set
Use the default refresh rate if the monitor limits aren't set (either using
data from the EDID block, or explicitly by the user).
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f1e5af..2e5f1b5 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -689,10 +689,13 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
/*
* If we don't get all necessary data from the EDID block,
-* mark it as incompatible with the GTF.
+* mark it as incompatible with the GTF and set nocrtc so
+* that we always use the default BIOS refresh rate.
*/
- if (uvesafb_vbe_getedid(task, info))
+ if (uvesafb_vbe_getedid(task, info)) {
info->monspecs.gtf = 0;
+ par->nocrtc = 1;
+ }
/* Kernel command line overrides. */
if (maxclk)
@@ -711,6 +714,7 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
info->monspecs.vfmin = 60;
info->monspecs.hfmin = 29000;
info->monspecs.gtf = 1;
+ par->nocrtc = 0;
}
if (info->monspecs.gtf)
@@ -720,7 +724,8 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
(int)(info->monspecs.hfmax / 1000),
(int)(info->monspecs.dclkmax / 100));
else
- printk(KERN_INFO "uvesafb: no monitor limits have been set\n");
+ printk(KERN_INFO "uvesafb: no monitor limits have been set, "
+"default refresh rate will be used\n");
/* Add VBE modes to the modelist. */
for (i = 0; i < par->vbe_modes_cnt; i++) {
-
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/
[PATCH 7/7] uvesafb: try to set mode with default timings if setting it with our own timings failed
Sometimes the BIOS might not perform the mode switch correctly because of
the timings that we requested. In case this happens, try to set the video
mode with the default timings instead.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2e5f1b5..853323e 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -1218,6 +1218,7 @@ static int uvesafb_set_par(struct fb_info *info)
task = uvesafb_prep();
if (!task)
return -ENOMEM;
+setmode:
task->t.regs.eax = 0x4f02;
task->t.regs.ebx = mode->mode_id | 0x4000; /* use LFB */
@@ -1260,10 +1261,25 @@ static int uvesafb_set_par(struct fb_info *info)
err = uvesafb_exec(task);
if (err || (task->t.regs.eax & 0x) != 0x004f) {
- printk(KERN_ERR "uvesafb: mode switch failed (eax=0x%x, "
- "err=%d)\n", task->t.regs.eax, err);
- err = -EINVAL;
- goto out;
+ /*
+* The mode switch might have failed because we tried to
+* use our own timings. Try again with the default timings.
+*/
+ if (crtc != NULL) {
+ printk(KERN_WARNING "uvesafb: mode switch failed "
+ "(eax=0x%x, err=%d). Trying again with "
+ "default timings.\n", task->t.regs.eax, err);
+ uvesafb_reset(task);
+ kfree(crtc);
+ crtc = NULL;
+ info->var.pixclock = 0;
+ goto setmode;
+ } else {
+ printk(KERN_ERR "uvesafb: mode switch failed (eax="
+ "0x%x, err=%d)\n", task->t.regs.eax, err);
+ err = -EINVAL;
+ goto out;
+ }
}
par->mode_idx = i;
-
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/
[PATCH 5/7] uvesafb: use VISUAL_TRUECOLOR as the default visual
Set uvesafb's default visual to truecolor. This prevents fbcon
from being detected as 'mono' when using uvesafb.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index e480670..2f1e5af 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -37,6 +37,7 @@ static struct fb_fix_screeninfo uvesafb_fix __devinitdata = {
.id = "VESA VGA",
.type = FB_TYPE_PACKED_PIXELS,
.accel = FB_ACCEL_NONE,
+ .visual = FB_VISUAL_TRUECOLOR,
};
static int mtrr__devinitdata = 3; /* enable mtrr by default */
-
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/
[PATCH 3/7] uvesafb: fix a typo in a warning
Replace "vesafb" with "uvesafb" in a kernel warning message. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -408,7 +412,7 @@ static void uvesafb_vbe_state_restore(struct uvesafb_par *par, u8 *state_buf) err = uvesafb_exec(task); if (err || (task->t.regs.eax & 0x) != 0x004f) - printk(KERN_WARNING "vesafb: VBE state restore call " + printk(KERN_WARNING "uvesafb: VBE state restore call " "failed (eax=0x%x, err=%d)\n", task->t.regs.eax, err); - 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/
[PATCH 4/7] uvesafb: add info about pmipal, yrap and ypan being available only on x86
Features that use the Protected Mode Interface are available on x86 only. Document this in the uvesafb description. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index cfc4e55..1a3b65b 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt @@ -59,11 +59,12 @@ Accepted options: ypanEnable display panning using the VESA protected mode interface. The visible screen is just a window of the video memory, console scrolling is done by changing the -start of the window. +start of the window. Available on x86 only. ywrap Same as ypan, but assumes your gfx board can wrap-around the video memory (i.e. starts reading from top if it reaches the end of video memory). Faster than ypan. +Available on x86 only. redraw Scroll by redrawing the affected part of the screen, this is the safe (and slow) default. @@ -75,7 +76,7 @@ vgapal Use the standard VGA registers for palette changes. pmipal Use the protected mode interface for palette changes. This is the default if the protected mode interface is -available. +available. Available on x86 only. mtrr:n Setup memory type range registers for the framebuffer where n: - 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/
[PATCH 2/7] uvesafb: always use mutexes when accessing uvfb_tasks
Accesses to the uvfb_tasks array should be always be protected by a mutex to avoid race conditions. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index aa5a9c3..e480670 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -208,6 +208,10 @@ static int uvesafb_exec(struct uvesafb_ktask *task) err = !wait_for_completion_timeout(task->done, msecs_to_jiffies(UVESAFB_TIMEOUT)); + mutex_lock(_lock); + uvfb_tasks[seq] = NULL; + mutex_unlock(_lock); + seq++; if (seq >= UVESAFB_TASKS_MAX) seq = 0; - 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/
[PATCH 1/7] uvesafb: set the refresh rate to 60Hz if nocrtc is used
If the nocrtc flag is set, make sure the timings in fb_var are set to 60Hz and thus reflect the default BIOS refresh rate that is being used. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index 9c21791..aa5a9c3 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -903,7 +903,7 @@ gotmode: * If we are not VBE3.0+ compliant, we're done -- the BIOS will * ignore our timings anyway. */ - if (par->vbe_ib.vbe_version < 0x0300) + if (par->vbe_ib.vbe_version < 0x0300 || par->nocrtc) fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON, 60, >var, info); - 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/
[PATCH 0/7] uvesafb: miscellaneous fixes and updates
This set of patches fixes several minor issues with uvesafb. It requires all previous uvesafb patches (currently in -mm). -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH 0/7] uvesafb: miscellaneous fixes and updates
This set of patches fixes several minor issues with uvesafb. It requires all previous uvesafb patches (currently in -mm). -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH 1/7] uvesafb: set the refresh rate to 60Hz if nocrtc is used
If the nocrtc flag is set, make sure the timings in fb_var are set to 60Hz and thus reflect the default BIOS refresh rate that is being used. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index 9c21791..aa5a9c3 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -903,7 +903,7 @@ gotmode: * If we are not VBE3.0+ compliant, we're done -- the BIOS will * ignore our timings anyway. */ - if (par-vbe_ib.vbe_version 0x0300) + if (par-vbe_ib.vbe_version 0x0300 || par-nocrtc) fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON, 60, info-var, info); - 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/
[PATCH 2/7] uvesafb: always use mutexes when accessing uvfb_tasks
Accesses to the uvfb_tasks array should be always be protected by a mutex to avoid race conditions. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index aa5a9c3..e480670 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -208,6 +208,10 @@ static int uvesafb_exec(struct uvesafb_ktask *task) err = !wait_for_completion_timeout(task-done, msecs_to_jiffies(UVESAFB_TIMEOUT)); + mutex_lock(uvfb_lock); + uvfb_tasks[seq] = NULL; + mutex_unlock(uvfb_lock); + seq++; if (seq = UVESAFB_TASKS_MAX) seq = 0; - 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/
[PATCH 3/7] uvesafb: fix a typo in a warning
Replace vesafb with uvesafb in a kernel warning message. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -408,7 +412,7 @@ static void uvesafb_vbe_state_restore(struct uvesafb_par *par, u8 *state_buf) err = uvesafb_exec(task); if (err || (task-t.regs.eax 0x) != 0x004f) - printk(KERN_WARNING vesafb: VBE state restore call + printk(KERN_WARNING uvesafb: VBE state restore call failed (eax=0x%x, err=%d)\n, task-t.regs.eax, err); - 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/
[PATCH 4/7] uvesafb: add info about pmipal, yrap and ypan being available only on x86
Features that use the Protected Mode Interface are available on x86 only. Document this in the uvesafb description. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index cfc4e55..1a3b65b 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt @@ -59,11 +59,12 @@ Accepted options: ypanEnable display panning using the VESA protected mode interface. The visible screen is just a window of the video memory, console scrolling is done by changing the -start of the window. +start of the window. Available on x86 only. ywrap Same as ypan, but assumes your gfx board can wrap-around the video memory (i.e. starts reading from top if it reaches the end of video memory). Faster than ypan. +Available on x86 only. redraw Scroll by redrawing the affected part of the screen, this is the safe (and slow) default. @@ -75,7 +76,7 @@ vgapal Use the standard VGA registers for palette changes. pmipal Use the protected mode interface for palette changes. This is the default if the protected mode interface is -available. +available. Available on x86 only. mtrr:n Setup memory type range registers for the framebuffer where n: - 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/
[PATCH 5/7] uvesafb: use VISUAL_TRUECOLOR as the default visual
Set uvesafb's default visual to truecolor. This prevents fbcon
from being detected as 'mono' when using uvesafb.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index e480670..2f1e5af 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -37,6 +37,7 @@ static struct fb_fix_screeninfo uvesafb_fix __devinitdata = {
.id = VESA VGA,
.type = FB_TYPE_PACKED_PIXELS,
.accel = FB_ACCEL_NONE,
+ .visual = FB_VISUAL_TRUECOLOR,
};
static int mtrr__devinitdata = 3; /* enable mtrr by default */
-
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/
[PATCH 6/7] uvesafb: use the default refresh rate if the monitor limits are not set
Use the default refresh rate if the monitor limits aren't set (either using
data from the EDID block, or explicitly by the user).
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f1e5af..2e5f1b5 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -689,10 +689,13 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
/*
* If we don't get all necessary data from the EDID block,
-* mark it as incompatible with the GTF.
+* mark it as incompatible with the GTF and set nocrtc so
+* that we always use the default BIOS refresh rate.
*/
- if (uvesafb_vbe_getedid(task, info))
+ if (uvesafb_vbe_getedid(task, info)) {
info-monspecs.gtf = 0;
+ par-nocrtc = 1;
+ }
/* Kernel command line overrides. */
if (maxclk)
@@ -711,6 +714,7 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
info-monspecs.vfmin = 60;
info-monspecs.hfmin = 29000;
info-monspecs.gtf = 1;
+ par-nocrtc = 0;
}
if (info-monspecs.gtf)
@@ -720,7 +724,8 @@ static void __devinit uvesafb_vbe_getmonspecs(struct
uvesafb_ktask *task,
(int)(info-monspecs.hfmax / 1000),
(int)(info-monspecs.dclkmax / 100));
else
- printk(KERN_INFO uvesafb: no monitor limits have been set\n);
+ printk(KERN_INFO uvesafb: no monitor limits have been set,
+default refresh rate will be used\n);
/* Add VBE modes to the modelist. */
for (i = 0; i par-vbe_modes_cnt; i++) {
-
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/
[PATCH 7/7] uvesafb: try to set mode with default timings if setting it with our own timings failed
Sometimes the BIOS might not perform the mode switch correctly because of
the timings that we requested. In case this happens, try to set the video
mode with the default timings instead.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2e5f1b5..853323e 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -1218,6 +1218,7 @@ static int uvesafb_set_par(struct fb_info *info)
task = uvesafb_prep();
if (!task)
return -ENOMEM;
+setmode:
task-t.regs.eax = 0x4f02;
task-t.regs.ebx = mode-mode_id | 0x4000; /* use LFB */
@@ -1260,10 +1261,25 @@ static int uvesafb_set_par(struct fb_info *info)
err = uvesafb_exec(task);
if (err || (task-t.regs.eax 0x) != 0x004f) {
- printk(KERN_ERR uvesafb: mode switch failed (eax=0x%x,
- err=%d)\n, task-t.regs.eax, err);
- err = -EINVAL;
- goto out;
+ /*
+* The mode switch might have failed because we tried to
+* use our own timings. Try again with the default timings.
+*/
+ if (crtc != NULL) {
+ printk(KERN_WARNING uvesafb: mode switch failed
+ (eax=0x%x, err=%d). Trying again with
+ default timings.\n, task-t.regs.eax, err);
+ uvesafb_reset(task);
+ kfree(crtc);
+ crtc = NULL;
+ info-var.pixclock = 0;
+ goto setmode;
+ } else {
+ printk(KERN_ERR uvesafb: mode switch failed (eax=
+ 0x%x, err=%d)\n, task-t.regs.eax, err);
+ err = -EINVAL;
+ goto out;
+ }
}
par-mode_idx = i;
-
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/
[PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
Currently if the refresh rate is not specified fb_find_mode() returns
the first known video mode with the requested resoluion, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned instead.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..f70143a 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,26 +606,29 @@ done:
DPRINTK("Trying specified video mode%s %ix%i\n",
refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
- diff = refresh;
+ if (!refresh_specified)
+ diff = 0
+ else
+ diff = refresh;
+
best = -1;
for (i = 0; i < dbsize; i++) {
- if (name_matches(db[i], name, namelen) ||
- (res_specified && res_matches(db[i], xres, yres))) {
- if(!fb_try_mode(var, info, [i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
- return 1;
- else {
- if(diff > abs(db[i].refresh - refresh))
{
- diff = abs(db[i].refresh -
refresh);
- best = i;
- }
+ if ((name_matches(db[i], name, namelen) ||
+ (res_specified && res_matches(db[i], xres, yres))) &&
+ !fb_try_mode(var, info, [i], bpp)) {
+ if (refresh_specified && db[i].refresh == refresh) {
+ return 1;
+ } else {
+ if (diff < db[i].refresh) {
+ diff = db[i].refresh;
+ best = i;
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
diff = xres + yres;
-
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/
[PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
Currently if the refresh rate is not specified fb_find_mode() returns
the first known video mode with the requested resoluion, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned instead.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..f70143a 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,26 +606,29 @@ done:
DPRINTK(Trying specified video mode%s %ix%i\n,
refresh_specified ? : (ignoring refresh rate), xres, yres);
- diff = refresh;
+ if (!refresh_specified)
+ diff = 0
+ else
+ diff = refresh;
+
best = -1;
for (i = 0; i dbsize; i++) {
- if (name_matches(db[i], name, namelen) ||
- (res_specified res_matches(db[i], xres, yres))) {
- if(!fb_try_mode(var, info, db[i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
- return 1;
- else {
- if(diff abs(db[i].refresh - refresh))
{
- diff = abs(db[i].refresh -
refresh);
- best = i;
- }
+ if ((name_matches(db[i], name, namelen) ||
+ (res_specified res_matches(db[i], xres, yres)))
+ !fb_try_mode(var, info, db[i], bpp)) {
+ if (refresh_specified db[i].refresh == refresh) {
+ return 1;
+ } else {
+ if (diff db[i].refresh) {
+ diff = db[i].refresh;
+ best = i;
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, db[best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
diff = xres + yres;
-
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/
[PATCH v2 3/5] uvesafb: change connector's max message size
Change the maximum message size to 16k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- This patch increases the limit to 16k since the previous value (4k) proved to be insufficient for the hardware state buffer on some video cards. include/linux/connector.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 14cecaf..12e3140 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -44,7 +44,7 @@ /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 16384 /* * idx and val are unique identifiers which - 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 v2 0/5] uvesafb: a general description
On Thu, Jul 05, 2007 at 01:38:46PM -0400, Ryan Hope wrote: > I applied > > http://dev.gentoo.org/~spock/projects/uvesafb/archive/uvesafb-0.1-rc2-2.6.22-rc6.patchto > 2.6.22-rc6-mm1... everything seems to be working properly. However, in dmesg > I did notice the following message: > > uvesafb: message too long (9872), can't execute task > uvesafb: VBE get state call failed (eax=0x4f04, err=-7) > > The messages seem to get generated when I switch VTs. Just thought I would > let you know. If there is anything else I can do to help let me know. It looks like the VBE hardware state buffer for your video card is larger than the 4k currently supported by connector. The problem should be easily fixed by setting CONNECTOR_MAX_MSG_SIZE in include/linux/connector.h to e.g. 16k. I've already updated the patch on my website, so next time you download it, the error messages should be gone. Best regards, Michal - 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 v2 0/5] uvesafb: a general description
On Thu, Jul 05, 2007 at 01:38:46PM -0400, Ryan Hope wrote: I applied http://dev.gentoo.org/~spock/projects/uvesafb/archive/uvesafb-0.1-rc2-2.6.22-rc6.patchto 2.6.22-rc6-mm1... everything seems to be working properly. However, in dmesg I did notice the following message: uvesafb: message too long (9872), can't execute task uvesafb: VBE get state call failed (eax=0x4f04, err=-7) The messages seem to get generated when I switch VTs. Just thought I would let you know. If there is anything else I can do to help let me know. It looks like the VBE hardware state buffer for your video card is larger than the 4k currently supported by connector. The problem should be easily fixed by setting CONNECTOR_MAX_MSG_SIZE in include/linux/connector.h to e.g. 16k. I've already updated the patch on my website, so next time you download it, the error messages should be gone. Best regards, Michal - 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/
[PATCH v2 3/5] uvesafb: change connector's max message size
Change the maximum message size to 16k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- This patch increases the limit to 16k since the previous value (4k) proved to be insufficient for the hardware state buffer on some video cards. include/linux/connector.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 14cecaf..12e3140 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -44,7 +44,7 @@ /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 16384 /* * idx and val are unique identifiers which - 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 0/4] fbdev: uvesafb
On Tue, Jun 26, 2007 at 11:42:41AM +0100, Jonathan McDowell wrote: > Have you considered using libx86[1] in v86d? It looks very similar to > what you have at present and there are plans to extend it to non > x86(_64) archs. It looks like an interesting solution and it is indeed similar to what I'm currently using. I'll consider switching to it in the next version of v86d. Thanks, Michal - 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/
[PATCH v2 5/5] uvesafb: documentation
Documentation for the uvesafb driver. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- Documentation/fb/uvesafb.txt | 187 ++ 1 files changed, 187 insertions(+), 0 deletions(-) diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt new file mode 100644 index 000..cfc4e55 --- /dev/null +++ b/Documentation/fb/uvesafb.txt @@ -0,0 +1,187 @@ + +uvesafb - A Generic Driver for VBE2+ compliant video cards +== + +1. Requirements +--- + +uvesafb should work with any video card that has a Video BIOS compliant +with the VBE 2.0 standard. + +Unlike other drivers, uvesafb makes use of a userspace helper called +v86d. v86d is used to run the x86 Video BIOS code in a simulated and +controlled environment. This allows uvesafb to function on arches other +than x86. Check the v86d documentation for a list of currently supported +arches. + +v86d source code can be downloaded from the following website: + http://dev.gentoo.org/~spock/projects/uvesafb + +Please refer to the v86d documentation for detailed configuration and +installation instructions. + +Note that the v86d userspace helper has to be available at all times in +order for uvesafb to work properly. If you want to use uvesafb during +early boot, you will have to include v86d into an initramfs image, and +either compile it into the kernel or use it as an initrd. + +2. Caveats and limitations +-- + +uvesafb is a _generic_ driver which supports a wide variety of video +cards, but which is ultimately limited by the Video BIOS interface. +The most important limitations are: + +- Lack of any type of acceleration. +- A strict and limited set of supported video modes. Often the native + or most optimal resolution/refresh rate for your setup will not work + with uvesafb, simply because the Video BIOS doesn't support the + video mode you want to use. This can be especially painful with + widescreen panels, where native video modes don't have the 4:3 aspect + ratio, which is what most BIOS-es are limited to. +- Adjusting the refresh rate is only possible with a VBE 3.0 compliant + Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 + compliant, while they simply ignore any refresh rate settings. + +3. Configuration + + +uvesafb can be compiled either as a module, or directly into the kernel. +In both cases it supports the same set of configuration options, which +are either given on the kernel command line or as module parameters, e.g.: + + video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) + + # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + +Accepted options: + +ypanEnable display panning using the VESA protected mode +interface. The visible screen is just a window of the +video memory, console scrolling is done by changing the +start of the window. + +ywrap Same as ypan, but assumes your gfx board can wrap-around +the video memory (i.e. starts reading from top if it +reaches the end of video memory). Faster than ypan. + +redraw Scroll by redrawing the affected part of the screen, this +is the safe (and slow) default. + +(If you're using uvesafb as a module, the above three options are + used a parameter of the scroll option, e.g. scroll=ypan.) + +vgapal Use the standard VGA registers for palette changes. + +pmipal Use the protected mode interface for palette changes. +This is the default if the protected mode interface is +available. + +mtrr:n Setup memory type range registers for the framebuffer +where n: + 0 - disabled (equivalent to nomtrr) (default) + 1 - uncachable + 2 - write-back + 3 - write-combining + 4 - write-through + +If you see the following in dmesg, choose the type that matches +the old one. In this example, use "mtrr:2". +... +mtrr: type mismatch for e000,800 old: write-back new: write-combining +... + +nomtrr Do not use memory type range registers. + +vremap:n +Remap 'n' MiB of video RAM. If 0 or not specified, remap memory +according to video mode. + +vtotal:n +If the video BIOS of your card incorrectly determines the total +amount of video RAM, use this option to override the BIOS (in MiB). + + The mode you want to set, in the standard modedb format. Refer to +modedb.txt for a detailed description. When uvesafb is compiled as +a module, the mode string should be provided as a value of the +'mode' option. + +vbemode:x +Force the use of VBE mode x. The mode will only be set if it's +found in the VBE-provided list of supported modes. +NOTE: The mode number 'x' should be specified in VESA mode number +notation, not the Linux kernel one
[PATCH v2 3/5] uvesafb: change connector's max message size
Change the maximum message size to 4k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- include/linux/connector.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 14cecaf..12e3140 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -44,7 +44,7 @@ /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 4096 /* * idx and val are unique identifiers which - 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/
[PATCH v2 2/5] uvesafb: add connector entries
Add connector idx and val constants for v86d and uvesafb. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- include/linux/connector.h |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 10eb56b..14cecaf 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -36,9 +36,10 @@ #define CN_VAL_CIFS 0x1 #define CN_W1_IDX 0x3 /* w1 communication */ #define CN_W1_VAL 0x1 +#define CN_IDX_V86D0x4 +#define CN_VAL_V86D_UVESAFB0x1 - -#define CN_NETLINK_USERS 4 +#define CN_NETLINK_USERS 5 /* * Maximum connector's message size. - 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/
[PATCH v2 1/5] uvesafb: export fb_destroy_modelist
Make fb_destroy_modelist an exported symbol for use in the uvesafb driver. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- drivers/video/modedb.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c index 3741ad7..d351eed 100644 --- a/drivers/video/modedb.c +++ b/drivers/video/modedb.c @@ -938,6 +938,7 @@ void fb_destroy_modelist(struct list_head *head) kfree(pos); } } +EXPORT_SYMBOL_GPL(fb_destroy_modelist); /** * fb_videomode_to_modelist: convert mode array to mode list - 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/
[PATCH v2 0/5] uvesafb: a general description
uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced version of vesafb and a direct successor of vesafb-tng [1]. This is the second version of this patch, and it incorporates all fixes and cleanups suggested on the lkml. My thanks to everyone who took their time to review the first version. uvesafb uses a userspace helper application (v86d, [2]) to run the x86 Video BIOS code. This makes it possible to include in uvesafb all the standard features (refresh rate control, video mode changes etc) that are missing from vesafb without resorting to ugly hacks such as the ones used in [1]. The current implementation of v86d can use either LRMI or x86emu to run the BIOS code and supports both x86 and x86_64. [1] http://dev.gentoo.org/~spock/projects/vesafb-tng/ [2] http://dev.gentoo.org/~spock/projects/uvesafb/ Best regards. -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH v2 0/5] uvesafb: a general description
uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced version of vesafb and a direct successor of vesafb-tng [1]. This is the second version of this patch, and it incorporates all fixes and cleanups suggested on the lkml. My thanks to everyone who took their time to review the first version. uvesafb uses a userspace helper application (v86d, [2]) to run the x86 Video BIOS code. This makes it possible to include in uvesafb all the standard features (refresh rate control, video mode changes etc) that are missing from vesafb without resorting to ugly hacks such as the ones used in [1]. The current implementation of v86d can use either LRMI or x86emu to run the BIOS code and supports both x86 and x86_64. [1] http://dev.gentoo.org/~spock/projects/vesafb-tng/ [2] http://dev.gentoo.org/~spock/projects/uvesafb/ Best regards. -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH v2 1/5] uvesafb: export fb_destroy_modelist
Make fb_destroy_modelist an exported symbol for use in the uvesafb driver. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- drivers/video/modedb.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c index 3741ad7..d351eed 100644 --- a/drivers/video/modedb.c +++ b/drivers/video/modedb.c @@ -938,6 +938,7 @@ void fb_destroy_modelist(struct list_head *head) kfree(pos); } } +EXPORT_SYMBOL_GPL(fb_destroy_modelist); /** * fb_videomode_to_modelist: convert mode array to mode list - 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/
[PATCH v2 2/5] uvesafb: add connector entries
Add connector idx and val constants for v86d and uvesafb. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- include/linux/connector.h |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 10eb56b..14cecaf 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -36,9 +36,10 @@ #define CN_VAL_CIFS 0x1 #define CN_W1_IDX 0x3 /* w1 communication */ #define CN_W1_VAL 0x1 +#define CN_IDX_V86D0x4 +#define CN_VAL_V86D_UVESAFB0x1 - -#define CN_NETLINK_USERS 4 +#define CN_NETLINK_USERS 5 /* * Maximum connector's message size. - 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/
[PATCH v2 3/5] uvesafb: change connector's max message size
Change the maximum message size to 4k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- include/linux/connector.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 14cecaf..12e3140 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -44,7 +44,7 @@ /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 4096 /* * idx and val are unique identifiers which - 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/
[PATCH v2 5/5] uvesafb: documentation
Documentation for the uvesafb driver. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- Documentation/fb/uvesafb.txt | 187 ++ 1 files changed, 187 insertions(+), 0 deletions(-) diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt new file mode 100644 index 000..cfc4e55 --- /dev/null +++ b/Documentation/fb/uvesafb.txt @@ -0,0 +1,187 @@ + +uvesafb - A Generic Driver for VBE2+ compliant video cards +== + +1. Requirements +--- + +uvesafb should work with any video card that has a Video BIOS compliant +with the VBE 2.0 standard. + +Unlike other drivers, uvesafb makes use of a userspace helper called +v86d. v86d is used to run the x86 Video BIOS code in a simulated and +controlled environment. This allows uvesafb to function on arches other +than x86. Check the v86d documentation for a list of currently supported +arches. + +v86d source code can be downloaded from the following website: + http://dev.gentoo.org/~spock/projects/uvesafb + +Please refer to the v86d documentation for detailed configuration and +installation instructions. + +Note that the v86d userspace helper has to be available at all times in +order for uvesafb to work properly. If you want to use uvesafb during +early boot, you will have to include v86d into an initramfs image, and +either compile it into the kernel or use it as an initrd. + +2. Caveats and limitations +-- + +uvesafb is a _generic_ driver which supports a wide variety of video +cards, but which is ultimately limited by the Video BIOS interface. +The most important limitations are: + +- Lack of any type of acceleration. +- A strict and limited set of supported video modes. Often the native + or most optimal resolution/refresh rate for your setup will not work + with uvesafb, simply because the Video BIOS doesn't support the + video mode you want to use. This can be especially painful with + widescreen panels, where native video modes don't have the 4:3 aspect + ratio, which is what most BIOS-es are limited to. +- Adjusting the refresh rate is only possible with a VBE 3.0 compliant + Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 + compliant, while they simply ignore any refresh rate settings. + +3. Configuration + + +uvesafb can be compiled either as a module, or directly into the kernel. +In both cases it supports the same set of configuration options, which +are either given on the kernel command line or as module parameters, e.g.: + + video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) + + # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + +Accepted options: + +ypanEnable display panning using the VESA protected mode +interface. The visible screen is just a window of the +video memory, console scrolling is done by changing the +start of the window. + +ywrap Same as ypan, but assumes your gfx board can wrap-around +the video memory (i.e. starts reading from top if it +reaches the end of video memory). Faster than ypan. + +redraw Scroll by redrawing the affected part of the screen, this +is the safe (and slow) default. + +(If you're using uvesafb as a module, the above three options are + used a parameter of the scroll option, e.g. scroll=ypan.) + +vgapal Use the standard VGA registers for palette changes. + +pmipal Use the protected mode interface for palette changes. +This is the default if the protected mode interface is +available. + +mtrr:n Setup memory type range registers for the framebuffer +where n: + 0 - disabled (equivalent to nomtrr) (default) + 1 - uncachable + 2 - write-back + 3 - write-combining + 4 - write-through + +If you see the following in dmesg, choose the type that matches +the old one. In this example, use mtrr:2. +... +mtrr: type mismatch for e000,800 old: write-back new: write-combining +... + +nomtrr Do not use memory type range registers. + +vremap:n +Remap 'n' MiB of video RAM. If 0 or not specified, remap memory +according to video mode. + +vtotal:n +If the video BIOS of your card incorrectly determines the total +amount of video RAM, use this option to override the BIOS (in MiB). + +mode The mode you want to set, in the standard modedb format. Refer to +modedb.txt for a detailed description. When uvesafb is compiled as +a module, the mode string should be provided as a value of the +'mode' option. + +vbemode:x +Force the use of VBE mode x. The mode will only be set if it's +found in the VBE-provided list of supported modes. +NOTE: The mode number 'x' should be specified in VESA mode number +notation, not the Linux kernel one (eg. 257 instead
Re: [PATCH 0/4] fbdev: uvesafb
On Tue, Jun 26, 2007 at 11:42:41AM +0100, Jonathan McDowell wrote: Have you considered using libx86[1] in v86d? It looks very similar to what you have at present and there are plans to extend it to non x86(_64) archs. It looks like an interesting solution and it is indeed similar to what I'm currently using. I'll consider switching to it in the next version of v86d. Thanks, Michal - 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 3/4] fbdev: uvesafb driver
On Sat, Jun 23, 2007 at 04:36:39PM -0700, Andrew Morton wrote: > On Sun, 24 Jun 2007 01:20:33 +0200 Michal Januszewski <[EMAIL PROTECTED]> > wrote: > > > > > +config FB_UVESA > > > > + tristate "Userspace VESA VGA graphics support" > > > > + depends on FB && CONNECTOR > > > > > > These dependencies are insufficient. > > > > What exactly is missing here? A dep on X86? > > Yes. From your other comments it appears that a dependency on X86_32 is > needed. X86_32 is only needed for a bunch of specific operations that make use of the PMI. The driver can work without those (it has already been tested on X86_64, where PMI cannot be used). > > This would indicate the > > arches on which the driver has actually been tested. But which arches > > are supported and which aren't is, in the end, up to the userspace helper. > > The other architectures won't compile: they don't have mtrr.h That was my mistake of not putting the mtrr.h include inside a #ifdef CONFIG_MTRR. After fixing that and a few other things you pointed out in your previous message, I was able to successfully compile uvesafb for PPC (using a cross-compiler). Best regards, Michal - 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 3/4] fbdev: uvesafb driver
On Sat, Jun 23, 2007 at 04:36:39PM -0700, Andrew Morton wrote: On Sun, 24 Jun 2007 01:20:33 +0200 Michal Januszewski [EMAIL PROTECTED] wrote: +config FB_UVESA + tristate Userspace VESA VGA graphics support + depends on FB CONNECTOR These dependencies are insufficient. What exactly is missing here? A dep on X86? Yes. From your other comments it appears that a dependency on X86_32 is needed. X86_32 is only needed for a bunch of specific operations that make use of the PMI. The driver can work without those (it has already been tested on X86_64, where PMI cannot be used). This would indicate the arches on which the driver has actually been tested. But which arches are supported and which aren't is, in the end, up to the userspace helper. The other architectures won't compile: they don't have mtrr.h That was my mistake of not putting the mtrr.h include inside a #ifdef CONFIG_MTRR. After fixing that and a few other things you pointed out in your previous message, I was able to successfully compile uvesafb for PPC (using a cross-compiler). Best regards, Michal - 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 3/4] fbdev: uvesafb driver
On Sat, Jun 23, 2007 at 11:35:57AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:52:43 +0200 Michal Januszewski <[EMAIL PROTECTED]>
> wrote:
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 403dac7..5cc03f9 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -585,6 +585,24 @@ config FB_TGA
> >
> > Say Y if you have one of those.
> >
> > +config FB_UVESA
> > + tristate "Userspace VESA VGA graphics support"
> > + depends on FB && CONNECTOR
>
> These dependencies are insufficient.
What exactly is missing here? A dep on X86? This would indicate the
arches on which the driver has actually been tested. But which arches
are supported and which aren't is, in the end, up to the userspace helper.
> > +static struct cb_id uvesafb_cn_id = {
> > + .idx = CN_IDX_V86D,
> > + .val = CN_VAL_V86D_UVESAFB
> > +};
> > +static struct sock *nls;
> > +static char v86d_path[PATH_MAX] = "/sbin/v86d";
>
> Remove the PATH_MAX, save some memory.
>
> Oh, it gets set via sysfs. hrm.
Hmm, I guess I could make it a hard-coded value, but paths to userspace
helpers should generally be configurable, right?
> Now I'm wondering what this code actually does. It would be nice to have
> an overall design and implementation description in the changelog so we
> don't have to reverse-engineer your thoughts from your implementation...
OK, I'll include a more detailed description in the next round of the
patches.
> > +#ifdef __i386__
>
> CONFIG_X86 would be more typical.
>
> Be aware that CONFIG_X86 is true for both i386 and x86_64. You don't state
> whether this code works on x86_64. If it can, it should.
AFAIK, it can't. PMI code is meant to be run in 32-bit protected mode.
I'll add a note about this to the patch and change __i386__ to
CONFIG_X86_32.
> You might care to cc "H. Peter Anvin" <[EMAIL PROTECTED]> on the next version
> of this patch - he's a whizz at this sort of low-level x86 bios
> communication stuff.
Thanks, I'll do that.
> > + if (!request_mem_region(info->fix.smem_start, info->fix.smem_len,
> > + "uvesafb")) {
> > + printk(KERN_WARNING "uvesafb: cannot reserve video memory at "
> > + "0x%lx\n", info->fix.smem_start);
> > + /* We cannot make this fatal. Sometimes this comes from magic
> > + spaces our resource handlers simply don't know about. */
>
> so... what happens? The driver starts altering mrmory regions which it
> doesn't own?
Fixed. This was a leftover from vesafb.c. Are there any reasons for not
fixing it there as well?
> > +#ifndef MODULE
> > +static int __devinit uvesafb_setup(char *options)
> > +{
> > + char *this_opt;
> > +
> > + if (!options || !*options)
> > + return 0;
> > +
> > + while ((this_opt = strsep(, ",")) != NULL) {
> > + if (!*this_opt) continue;
> > +
> > + if (!strcmp(this_opt, "redraw"))
> > + ypan = 0;
> > + else if (!strcmp(this_opt, "ypan"))
> > + ypan = 1;
> > + else if (!strcmp(this_opt, "ywrap"))
> > + ypan = 2;
> > + else if (!strcmp(this_opt, "vgapal"))
> > + pmi_setpal = 0;
> > + else if (!strcmp(this_opt, "pmipal"))
> > + pmi_setpal = 1;
> > + else if (!strncmp(this_opt, "mtrr:", 5))
> > + mtrr = simple_strtoul(this_opt+5, NULL, 0);
> > + else if (!strcmp(this_opt, "nomtrr"))
> > + mtrr = 0;
> > + else if (!strcmp(this_opt, "nocrtc"))
> > + nocrtc = 1;
> > + else if (!strcmp(this_opt, "noedid"))
> > + noedid = 1;
> > + else if (!strcmp(this_opt, "noblank"))
> > + blank = 0;
> > + else if (!strncmp(this_opt, "vtotal:", 7))
> > + vram_total = simple_strtoul(this_opt + 7, NULL, 0);
> > + else if (!strncmp(this_opt, "vremap:", 7))
> > + vram_remap = simple_strtoul(this_opt + 7, NULL, 0);
> > + else if (!strncmp(this_opt, "maxhf:", 6))
> > + maxhf = simple_strtoul(this_opt + 6, NULL, 0);
> > + else if (!strncmp(this_opt, "maxvf:", 6))
> > +
Re: [PATCH 1/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
On Sat, Jun 23, 2007 at 11:04:24AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[EMAIL PROTECTED]>
> wrote:
>
> > + if (!refresh_specified)
> > + refresh = 200;
> > diff = refresh;
> > best = -1;
> > for (i = 0; i < dbsize; i++) {
> > if (name_matches(db[i], name, namelen) ||
> > (res_specified && res_matches(db[i], xres, yres))) {
> > if(!fb_try_mode(var, info, [i], bpp)) {
> > - if(!refresh_specified || db[i].refresh ==
> > refresh)
> > + if (refresh_specified && db[i].refresh ==
> > refresh)
> > return 1;
> > else {
> > - if(diff > abs(db[i].refresh - refresh))
> > {
> > + if (diff > abs(db[i].refresh -
> > refresh)) {
> > diff = abs(db[i].refresh -
> > refresh);
> > best = i;
> > }
> > @@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
> > kfree(pos);
> > }
> > }
> > +EXPORT_SYMBOL_GPL(fb_destroy_modelist);
> >
>
> fbdev ignoramus asks: isn't this pretty risky? People who were previously
> relying upon (or at least using) the kernel's default resolution will find
> their displays coming up in a quite different resolution.
The resolution will be unchanged (this part of the code is only executed
if either the name of the mode or the resolution are a match).
What can change is the refresh rate -- it can be set higher than what it
used to be before. But since we're checking all modes with fb_try_mode(),
(which calls fb_check_var()), I think that this change should be safe.
To avoid any side effects we could also do the following:
for (i = 0; i < dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, [i], bpp)) {
if (refresh_specified && db[i].refresh ==
refresh)
return 1;
else {
if (diff > abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
which would ensure that 1 is returned if the refresh rate is not
explicitly specified, just as it is done currently:
if(!refresh_specified || db[i].refresh ==
refresh)
return 1
I might be missing something here, so it would be nice if someone
involved in the fb development could comment on the proposed change.
> This change seems to be quite unrelated to the uvesafb stuff and should be
> in a separate patch from the export, which _is_ uvesafb-related. I think.
> If that's wrong then the changelog could do with some attention.
You're right, I'll split this into two patches in the next round.
Best regards,
Michal
-
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 0/4] fbdev: uvesafb
On Sat, Jun 23, 2007 at 02:04:09PM +0200, Arnd Bergmann wrote: > On Saturday 23 June 2007, Michal Januszewski wrote: > > Â The current implementation of v86d can use either LRMI or > > x86emu to run the BIOS code and supports both x86 and x86_64. > > Is there a fundamental reason why you can't also run it on > non-x86 machines, or has this simply not been tested so far? AFAIK it should be possible to get it to work on non-x86. One would have to implement the IO functions for x86emu and mmap the Video BIOS, both of which should be relatively easy tasks. I don't however have direct access to hardware other than x86(_64) and thus haven't had a chance to write such code and test it. Best regards, Michal - 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/
[PATCH 3/4] fbdev: uvesafb driver
Add the uvesafb driver, an enhanced version of vesafb that makes use of
a userspace helper to run x86 Video BIOS code.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
drivers/video/Kconfig | 18 +
drivers/video/Makefile |1 +
drivers/video/uvesafb.c | 1902 +++
include/video/Kbuild|2 +-
include/video/uvesafb.h | 208 ++
5 files changed, 2130 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 403dac7..5cc03f9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -585,6 +585,24 @@ config FB_TGA
Say Y if you have one of those.
+config FB_UVESA
+ tristate "Userspace VESA VGA graphics support"
+ depends on FB && CONNECTOR
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ help
+ This is the frame buffer driver for generic VBE 2.0 compliant
+ graphic cards. It can also take advantage of VBE 3.0 features,
+ such as refresh rate adjustment.
+
+ This driver generally provides more features than vesafb but
+ requires a userspace helper application called 'v86d'. See
+ for more information.
+
+ If unsure, say N.
+
config FB_VESA
bool "VESA VGA graphics support"
depends on (FB = y) && X86
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index bd8b052..b7da8c0 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
# Platform or fallback drivers go here
+obj-$(CONFIG_FB_UVESA)+= uvesafb.o
obj-$(CONFIG_FB_VESA) += vesafb.o
obj-$(CONFIG_FB_IMAC) += imacfb.o
obj-$(CONFIG_FB_VGA16)+= vga16fb.o
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
new file mode 100644
index 000..020597f
--- /dev/null
+++ b/drivers/video/uvesafb.c
@@ -0,0 +1,1902 @@
+/*
+ * A framebuffer driver for VBE 2.0+ compliant video cards
+ *
+ * (c) 2007 Michal Januszewski <[EMAIL PROTECTED]>
+ * Loosely based upon the vesafb driver.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "edid.h"
+
+static struct cb_id uvesafb_cn_id = {
+ .idx = CN_IDX_V86D,
+ .val = CN_VAL_V86D_UVESAFB
+};
+static struct sock *nls;
+static char v86d_path[PATH_MAX] = "/sbin/v86d";
+static char v86d_started = 0; /* has v86d been started by uvesafb? */
+
+static struct fb_fix_screeninfo uvesafb_fix __devinitdata = {
+ .id = "VESA VGA",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .accel = FB_ACCEL_NONE,
+};
+
+static int mtrr__devinitdata = 3; /* enable mtrr by default */
+static int blank __devinitdata = 1; /* enable blanking by default */
+static int ypan__devinitdata = 1; /* 0: scroll, 1: ypan, 2:
ywrap */
+static int pmi_setpal __devinitdata = 1; /* use PMI for palette changes */
+static int nocrtc __devinitdata = 0; /* ignore CRTC settings */
+static int noedid __devinitdata = 0; /* don't try DDC transfers */
+static int vram_remap __devinitdata = 0; /* set amt. of memory to be used */
+static int vram_total __devinitdata = 0; /* set total amount of memory */
+static u16 maxclk __devinitdata = 0; /* maximum pixel clock */
+static u16 maxvf __devinitdata = 0; /* maximum vertical frequency */
+static u16 maxhf __devinitdata = 0; /* maximum horizontal frequency */
+static u16 vbemode __devinitdata = 0; /* force use of a specific VBE mode
*/
+static char *mode_option __devinitdata = NULL;
+
+static struct uvesafb_ktask* uvfb_tasks[UVESAFB_TASKS_MAX];
+
+static void uvesafb_cn_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+ struct uvesafb_task *utask = (struct uvesafb_task *)msg->data;
+ struct uvesafb_ktask *task;
+
+ if (msg->seq >= UVESAFB_TASKS_MAX)
+ return;
+
+ task = uvfb_tasks[msg->seq];
+
+ if (!task || msg->ack != task->ack)
+ return;
+
+ memcpy(>t, utask, sizeof(struct uvesafb_task));
+
+ if (task->t.buf_len && task->buf)
+ memcpy(task->buf, ((u8*)utask) + sizeof(struct uvesafb_task),
+ task->t.buf_len);
+
+ complete(task->done);
+ return;
+}
+
+static int uvesafb_helper_start(void)
+{
+ char *envp[] = {
+ "HOME=/",
+ "PATH=/sbin:/bin",
+ NULL,
+ };
+
+ char *argv[] = {
+ v86d_path,
+ NULL,
+
[PATCH 1/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
If the refresh rate hasn't been explicitly specified, fd_find_mode
currently returns the first mode with the requested resolution. Change
it so that it returns a mode with the requested resolution and the
highest refresh rate.
Also export fb_destroy_modelist, which is used in uvesafb.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
drivers/video/modedb.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..98ee77b 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,16 +606,18 @@ done:
DPRINTK("Trying specified video mode%s %ix%i\n",
refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
+ if (!refresh_specified)
+ refresh = 200;
diff = refresh;
best = -1;
for (i = 0; i < dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, [i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
+ if (refresh_specified && db[i].refresh ==
refresh)
return 1;
else {
- if(diff > abs(db[i].refresh - refresh))
{
+ if (diff > abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
@@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
kfree(pos);
}
}
+EXPORT_SYMBOL_GPL(fb_destroy_modelist);
/**
* fb_videomode_to_modelist: convert mode array to mode list
-
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/
[PATCH 4/4] fbdev: uvesafb documentation
Add the documentation for the uvesafb driver. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- Documentation/fb/uvesafb.txt | 181 ++ 1 files changed, 181 insertions(+), 0 deletions(-) diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt new file mode 100644 index 000..894158e --- /dev/null +++ b/Documentation/fb/uvesafb.txt @@ -0,0 +1,181 @@ + +uvesafb - A Generic Driver for VBE2+ compliant video cards +== + +1. Requirements +--- + +uvesafb should work with any video card that has a Video BIOS compliant +with the VBE 2.0 standard. + +Unlike other drivers, uvesafb makes use of a userspace helper called +v86d. v86d is used to run the x86 Video BIOS code in a simulated and +controlled environment. This allows uvesafb to function on arches other +than x86. Check the v86d documentation for a list of currently supported +arches. + +v86d source code can be downloaded from the following website: + http://dev.gentoo.org/~spock/projects/uvesafb + +Please refer to the v86d documentation for detailed configuration and +installation instructions. + +Note that the v86d userspace helper has to be available at all times in +order for uvesafb to work properly. If you want to use uvesafb during +early boot, you will have to include v86d into an initramfs image, and +either compile it into the kernel or use it as an initrd. + +2. Caveats and limitations +-- + +uvesafb is a _generic_ driver which supports a wide variety of video +cards, but which is ultimately limited by the Video BIOS interface. +The most important limitations are: + +- Lack of any type of acceleration. +- A strict and limited set of supported video modes. Often the native + or most optimal resolution/refresh rate for your setup will not work + with uvesafb, simply because the Video BIOS doesn't support the + video mode you want to use. This can be especially painful with + widescreen panels, where native video modes don't have the 4:3 aspect + ratio, which is what most BIOS-es are limited to. +- Adjusting the refresh rate is only possible with a VBE 3.0 compliant + Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 + compliant, while they simply ignore any refresh rate settings. + +3. Configuration + + +uvesafb can be compiled either as a module, or directly into the kernel. +In both cases it supports the same set of configuration options, which +are either given on the kernel command line or as module parameters, e.g.: + + video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) + + # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + +Accepted options: + +ypanEnable display panning using the VESA protected mode +interface. The visible screen is just a window of the +video memory, console scrolling is done by changing the +start of the window. + +ywrap Same as ypan, but assumes your gfx board can wrap-around +the video memory (i.e. starts reading from top if it +reaches the end of video memory). Faster than ypan. + +redraw Scroll by redrawing the affected part of the screen, this +is the safe (and slow) default. + +(If you're using uvesafb as a module, the above three options are + used a parameter of the scroll option, e.g. scroll=ypan.) + +vgapal Use the standard VGA registers for palette changes. + +pmipal Use the protected mode interface for palette changes. +This is the default if the protected mode interface is +available. + +mtrr:n Setup memory type range registers for the framebuffer +where n: + 0 - disabled (equivalent to nomtrr) (default) + 1 - uncachable + 2 - write-back + 3 - write-combining + 4 - write-through + +If you see the following in dmesg, choose the type that matches +the old one. In this example, use "mtrr:2". +... +mtrr: type mismatch for e000,800 old: write-back new: write-combining +... + +nomtrr Do not use memory type range registers. + +vremap:n +Remap 'n' MiB of video RAM. If 0 or not specified, remap memory +according to video mode. + +vtotal:n +If the video BIOS of your card incorrectly determines the total +amount of video RAM, use this option to override the BIOS (in MiB). + + The mode you want to set, in the standard modedb format. Refer to +modedb.txt for a detailed description. When uvesafb is compiled as +a module, the mode string should be provided as a value of the +'mode' option. + +vbemode:x +Force the use of VBE mode x. The mode will only be set if it's +found in the VBE-provided list of supported modes. +NOTE: The mode number 'x' should be specified in VESA mode number +notation, not the Linux ker
[PATCH 0/4] fbdev: uvesafb
uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced version of vesafb and a direct successor of vesafb-tng [1]. uvesafb uses a userspace helper application (v86d, [2]) to run the x86 Video BIOS code. This makes it possible to include in uvesafb all the standard features (refresh rate control, video mode changes etc) that are missing from vesafb without resorting to ugly hacks such as the ones used in [1]. The current implementation of v86d can use either LRMI or x86emu to run the BIOS code and supports both x86 and x86_64. [1] http://dev.gentoo.org/~spock/projects/vesafb-tng/ [2] http://dev.gentoo.org/~spock/projects/uvesafb/ Best regards. -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH 2/4] fbdev: add connector entries for uvesafb
Add connector's idx and val constants for v86d and uvesafb. Also change the maximum message size to 4k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- include/linux/connector.h |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 10eb56b..46b2aba 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -36,14 +36,15 @@ #define CN_VAL_CIFS 0x1 #define CN_W1_IDX 0x3 /* w1 communication */ #define CN_W1_VAL 0x1 +#define CN_IDX_V86D0x4 +#define CN_VAL_V86D_UVESAFB0x1 - -#define CN_NETLINK_USERS 4 +#define CN_NETLINK_USERS 5 /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 4096 /* * idx and val are unique identifiers which - 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/
[PATCH 3/4] fbdev: uvesafb driver
Add the uvesafb driver, an enhanced version of vesafb that makes use of
a userspace helper to run x86 Video BIOS code.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
drivers/video/Kconfig | 18 +
drivers/video/Makefile |1 +
drivers/video/uvesafb.c | 1902 +++
include/video/Kbuild|2 +-
include/video/uvesafb.h | 208 ++
5 files changed, 2130 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 403dac7..5cc03f9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -585,6 +585,24 @@ config FB_TGA
Say Y if you have one of those.
+config FB_UVESA
+ tristate Userspace VESA VGA graphics support
+ depends on FB CONNECTOR
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ help
+ This is the frame buffer driver for generic VBE 2.0 compliant
+ graphic cards. It can also take advantage of VBE 3.0 features,
+ such as refresh rate adjustment.
+
+ This driver generally provides more features than vesafb but
+ requires a userspace helper application called 'v86d'. See
+ file:Documentation/fb/uvesafb.txt for more information.
+
+ If unsure, say N.
+
config FB_VESA
bool VESA VGA graphics support
depends on (FB = y) X86
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index bd8b052..b7da8c0 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
# Platform or fallback drivers go here
+obj-$(CONFIG_FB_UVESA)+= uvesafb.o
obj-$(CONFIG_FB_VESA) += vesafb.o
obj-$(CONFIG_FB_IMAC) += imacfb.o
obj-$(CONFIG_FB_VGA16)+= vga16fb.o
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
new file mode 100644
index 000..020597f
--- /dev/null
+++ b/drivers/video/uvesafb.c
@@ -0,0 +1,1902 @@
+/*
+ * A framebuffer driver for VBE 2.0+ compliant video cards
+ *
+ * (c) 2007 Michal Januszewski [EMAIL PROTECTED]
+ * Loosely based upon the vesafb driver.
+ *
+ */
+#include linux/init.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/skbuff.h
+#include linux/timer.h
+#include linux/completion.h
+#include linux/connector.h
+#include linux/random.h
+#include linux/platform_device.h
+#include linux/limits.h
+#include linux/fb.h
+#include video/edid.h
+#include video/vga.h
+#include video/uvesafb.h
+#include asm/io.h
+#include asm/mtrr.h
+
+#include edid.h
+
+static struct cb_id uvesafb_cn_id = {
+ .idx = CN_IDX_V86D,
+ .val = CN_VAL_V86D_UVESAFB
+};
+static struct sock *nls;
+static char v86d_path[PATH_MAX] = /sbin/v86d;
+static char v86d_started = 0; /* has v86d been started by uvesafb? */
+
+static struct fb_fix_screeninfo uvesafb_fix __devinitdata = {
+ .id = VESA VGA,
+ .type = FB_TYPE_PACKED_PIXELS,
+ .accel = FB_ACCEL_NONE,
+};
+
+static int mtrr__devinitdata = 3; /* enable mtrr by default */
+static int blank __devinitdata = 1; /* enable blanking by default */
+static int ypan__devinitdata = 1; /* 0: scroll, 1: ypan, 2:
ywrap */
+static int pmi_setpal __devinitdata = 1; /* use PMI for palette changes */
+static int nocrtc __devinitdata = 0; /* ignore CRTC settings */
+static int noedid __devinitdata = 0; /* don't try DDC transfers */
+static int vram_remap __devinitdata = 0; /* set amt. of memory to be used */
+static int vram_total __devinitdata = 0; /* set total amount of memory */
+static u16 maxclk __devinitdata = 0; /* maximum pixel clock */
+static u16 maxvf __devinitdata = 0; /* maximum vertical frequency */
+static u16 maxhf __devinitdata = 0; /* maximum horizontal frequency */
+static u16 vbemode __devinitdata = 0; /* force use of a specific VBE mode
*/
+static char *mode_option __devinitdata = NULL;
+
+static struct uvesafb_ktask* uvfb_tasks[UVESAFB_TASKS_MAX];
+
+static void uvesafb_cn_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+ struct uvesafb_task *utask = (struct uvesafb_task *)msg-data;
+ struct uvesafb_ktask *task;
+
+ if (msg-seq = UVESAFB_TASKS_MAX)
+ return;
+
+ task = uvfb_tasks[msg-seq];
+
+ if (!task || msg-ack != task-ack)
+ return;
+
+ memcpy(task-t, utask, sizeof(struct uvesafb_task));
+
+ if (task-t.buf_len task-buf)
+ memcpy(task-buf, ((u8*)utask) + sizeof(struct uvesafb_task),
+ task-t.buf_len);
+
+ complete(task-done);
+ return;
+}
+
+static int uvesafb_helper_start(void)
+{
+ char *envp[] = {
+ HOME=/,
+ PATH=/sbin:/bin,
+ NULL
[PATCH 4/4] fbdev: uvesafb documentation
Add the documentation for the uvesafb driver. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- Documentation/fb/uvesafb.txt | 181 ++ 1 files changed, 181 insertions(+), 0 deletions(-) diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt new file mode 100644 index 000..894158e --- /dev/null +++ b/Documentation/fb/uvesafb.txt @@ -0,0 +1,181 @@ + +uvesafb - A Generic Driver for VBE2+ compliant video cards +== + +1. Requirements +--- + +uvesafb should work with any video card that has a Video BIOS compliant +with the VBE 2.0 standard. + +Unlike other drivers, uvesafb makes use of a userspace helper called +v86d. v86d is used to run the x86 Video BIOS code in a simulated and +controlled environment. This allows uvesafb to function on arches other +than x86. Check the v86d documentation for a list of currently supported +arches. + +v86d source code can be downloaded from the following website: + http://dev.gentoo.org/~spock/projects/uvesafb + +Please refer to the v86d documentation for detailed configuration and +installation instructions. + +Note that the v86d userspace helper has to be available at all times in +order for uvesafb to work properly. If you want to use uvesafb during +early boot, you will have to include v86d into an initramfs image, and +either compile it into the kernel or use it as an initrd. + +2. Caveats and limitations +-- + +uvesafb is a _generic_ driver which supports a wide variety of video +cards, but which is ultimately limited by the Video BIOS interface. +The most important limitations are: + +- Lack of any type of acceleration. +- A strict and limited set of supported video modes. Often the native + or most optimal resolution/refresh rate for your setup will not work + with uvesafb, simply because the Video BIOS doesn't support the + video mode you want to use. This can be especially painful with + widescreen panels, where native video modes don't have the 4:3 aspect + ratio, which is what most BIOS-es are limited to. +- Adjusting the refresh rate is only possible with a VBE 3.0 compliant + Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 + compliant, while they simply ignore any refresh rate settings. + +3. Configuration + + +uvesafb can be compiled either as a module, or directly into the kernel. +In both cases it supports the same set of configuration options, which +are either given on the kernel command line or as module parameters, e.g.: + + video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) + + # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + +Accepted options: + +ypanEnable display panning using the VESA protected mode +interface. The visible screen is just a window of the +video memory, console scrolling is done by changing the +start of the window. + +ywrap Same as ypan, but assumes your gfx board can wrap-around +the video memory (i.e. starts reading from top if it +reaches the end of video memory). Faster than ypan. + +redraw Scroll by redrawing the affected part of the screen, this +is the safe (and slow) default. + +(If you're using uvesafb as a module, the above three options are + used a parameter of the scroll option, e.g. scroll=ypan.) + +vgapal Use the standard VGA registers for palette changes. + +pmipal Use the protected mode interface for palette changes. +This is the default if the protected mode interface is +available. + +mtrr:n Setup memory type range registers for the framebuffer +where n: + 0 - disabled (equivalent to nomtrr) (default) + 1 - uncachable + 2 - write-back + 3 - write-combining + 4 - write-through + +If you see the following in dmesg, choose the type that matches +the old one. In this example, use mtrr:2. +... +mtrr: type mismatch for e000,800 old: write-back new: write-combining +... + +nomtrr Do not use memory type range registers. + +vremap:n +Remap 'n' MiB of video RAM. If 0 or not specified, remap memory +according to video mode. + +vtotal:n +If the video BIOS of your card incorrectly determines the total +amount of video RAM, use this option to override the BIOS (in MiB). + +mode The mode you want to set, in the standard modedb format. Refer to +modedb.txt for a detailed description. When uvesafb is compiled as +a module, the mode string should be provided as a value of the +'mode' option. + +vbemode:x +Force the use of VBE mode x. The mode will only be set if it's +found in the VBE-provided list of supported modes. +NOTE: The mode number 'x' should be specified in VESA mode number +notation, not the Linux kernel one (eg. 257
[PATCH 2/4] fbdev: add connector entries for uvesafb
Add connector's idx and val constants for v86d and uvesafb. Also change the maximum message size to 4k to allow transfers of VBE data blocks from userspace. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- include/linux/connector.h |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 10eb56b..46b2aba 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -36,14 +36,15 @@ #define CN_VAL_CIFS 0x1 #define CN_W1_IDX 0x3 /* w1 communication */ #define CN_W1_VAL 0x1 +#define CN_IDX_V86D0x4 +#define CN_VAL_V86D_UVESAFB0x1 - -#define CN_NETLINK_USERS 4 +#define CN_NETLINK_USERS 5 /* * Maximum connector's message size. */ -#define CONNECTOR_MAX_MSG_SIZE 1024 +#define CONNECTOR_MAX_MSG_SIZE 4096 /* * idx and val are unique identifiers which - 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/
[PATCH 0/4] fbdev: uvesafb
uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced version of vesafb and a direct successor of vesafb-tng [1]. uvesafb uses a userspace helper application (v86d, [2]) to run the x86 Video BIOS code. This makes it possible to include in uvesafb all the standard features (refresh rate control, video mode changes etc) that are missing from vesafb without resorting to ugly hacks such as the ones used in [1]. The current implementation of v86d can use either LRMI or x86emu to run the BIOS code and supports both x86 and x86_64. [1] http://dev.gentoo.org/~spock/projects/vesafb-tng/ [2] http://dev.gentoo.org/~spock/projects/uvesafb/ Best regards. -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock - 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/
[PATCH 1/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
If the refresh rate hasn't been explicitly specified, fd_find_mode
currently returns the first mode with the requested resolution. Change
it so that it returns a mode with the requested resolution and the
highest refresh rate.
Also export fb_destroy_modelist, which is used in uvesafb.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
drivers/video/modedb.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..98ee77b 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,16 +606,18 @@ done:
DPRINTK(Trying specified video mode%s %ix%i\n,
refresh_specified ? : (ignoring refresh rate), xres, yres);
+ if (!refresh_specified)
+ refresh = 200;
diff = refresh;
best = -1;
for (i = 0; i dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, db[i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
+ if (refresh_specified db[i].refresh ==
refresh)
return 1;
else {
- if(diff abs(db[i].refresh - refresh))
{
+ if (diff abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
@@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
kfree(pos);
}
}
+EXPORT_SYMBOL_GPL(fb_destroy_modelist);
/**
* fb_videomode_to_modelist: convert mode array to mode list
-
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 0/4] fbdev: uvesafb
On Sat, Jun 23, 2007 at 02:04:09PM +0200, Arnd Bergmann wrote: On Saturday 23 June 2007, Michal Januszewski wrote: Â The current implementation of v86d can use either LRMI or x86emu to run the BIOS code and supports both x86 and x86_64. Is there a fundamental reason why you can't also run it on non-x86 machines, or has this simply not been tested so far? AFAIK it should be possible to get it to work on non-x86. One would have to implement the IO functions for x86emu and mmap the Video BIOS, both of which should be relatively easy tasks. I don't however have direct access to hardware other than x86(_64) and thus haven't had a chance to write such code and test it. Best regards, Michal - 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/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
On Sat, Jun 23, 2007 at 11:04:24AM -0700, Andrew Morton wrote:
On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski [EMAIL PROTECTED]
wrote:
+ if (!refresh_specified)
+ refresh = 200;
diff = refresh;
best = -1;
for (i = 0; i dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, db[i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
+ if (refresh_specified db[i].refresh ==
refresh)
return 1;
else {
- if(diff abs(db[i].refresh - refresh))
{
+ if (diff abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
@@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
kfree(pos);
}
}
+EXPORT_SYMBOL_GPL(fb_destroy_modelist);
fbdev ignoramus asks: isn't this pretty risky? People who were previously
relying upon (or at least using) the kernel's default resolution will find
their displays coming up in a quite different resolution.
The resolution will be unchanged (this part of the code is only executed
if either the name of the mode or the resolution are a match).
What can change is the refresh rate -- it can be set higher than what it
used to be before. But since we're checking all modes with fb_try_mode(),
(which calls fb_check_var()), I think that this change should be safe.
To avoid any side effects we could also do the following:
for (i = 0; i dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, db[i], bpp)) {
if (refresh_specified db[i].refresh ==
refresh)
return 1;
else {
if (diff abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, db[best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
which would ensure that 1 is returned if the refresh rate is not
explicitly specified, just as it is done currently:
if(!refresh_specified || db[i].refresh ==
refresh)
return 1
I might be missing something here, so it would be nice if someone
involved in the fb development could comment on the proposed change.
This change seems to be quite unrelated to the uvesafb stuff and should be
in a separate patch from the export, which _is_ uvesafb-related. I think.
If that's wrong then the changelog could do with some attention.
You're right, I'll split this into two patches in the next round.
Best regards,
Michal
-
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 3/4] fbdev: uvesafb driver
On Sat, Jun 23, 2007 at 11:35:57AM -0700, Andrew Morton wrote:
On Sat, 23 Jun 2007 12:52:43 +0200 Michal Januszewski [EMAIL PROTECTED]
wrote:
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 403dac7..5cc03f9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -585,6 +585,24 @@ config FB_TGA
Say Y if you have one of those.
+config FB_UVESA
+ tristate Userspace VESA VGA graphics support
+ depends on FB CONNECTOR
These dependencies are insufficient.
What exactly is missing here? A dep on X86? This would indicate the
arches on which the driver has actually been tested. But which arches
are supported and which aren't is, in the end, up to the userspace helper.
+static struct cb_id uvesafb_cn_id = {
+ .idx = CN_IDX_V86D,
+ .val = CN_VAL_V86D_UVESAFB
+};
+static struct sock *nls;
+static char v86d_path[PATH_MAX] = /sbin/v86d;
Remove the PATH_MAX, save some memory.
Oh, it gets set via sysfs. hrm.
Hmm, I guess I could make it a hard-coded value, but paths to userspace
helpers should generally be configurable, right?
Now I'm wondering what this code actually does. It would be nice to have
an overall design and implementation description in the changelog so we
don't have to reverse-engineer your thoughts from your implementation...
OK, I'll include a more detailed description in the next round of the
patches.
+#ifdef __i386__
CONFIG_X86 would be more typical.
Be aware that CONFIG_X86 is true for both i386 and x86_64. You don't state
whether this code works on x86_64. If it can, it should.
AFAIK, it can't. PMI code is meant to be run in 32-bit protected mode.
I'll add a note about this to the patch and change __i386__ to
CONFIG_X86_32.
You might care to cc H. Peter Anvin [EMAIL PROTECTED] on the next version
of this patch - he's a whizz at this sort of low-level x86 bios
communication stuff.
Thanks, I'll do that.
+ if (!request_mem_region(info-fix.smem_start, info-fix.smem_len,
+ uvesafb)) {
+ printk(KERN_WARNING uvesafb: cannot reserve video memory at
+ 0x%lx\n, info-fix.smem_start);
+ /* We cannot make this fatal. Sometimes this comes from magic
+ spaces our resource handlers simply don't know about. */
so... what happens? The driver starts altering mrmory regions which it
doesn't own?
Fixed. This was a leftover from vesafb.c. Are there any reasons for not
fixing it there as well?
+#ifndef MODULE
+static int __devinit uvesafb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((this_opt = strsep(options, ,)) != NULL) {
+ if (!*this_opt) continue;
+
+ if (!strcmp(this_opt, redraw))
+ ypan = 0;
+ else if (!strcmp(this_opt, ypan))
+ ypan = 1;
+ else if (!strcmp(this_opt, ywrap))
+ ypan = 2;
+ else if (!strcmp(this_opt, vgapal))
+ pmi_setpal = 0;
+ else if (!strcmp(this_opt, pmipal))
+ pmi_setpal = 1;
+ else if (!strncmp(this_opt, mtrr:, 5))
+ mtrr = simple_strtoul(this_opt+5, NULL, 0);
+ else if (!strcmp(this_opt, nomtrr))
+ mtrr = 0;
+ else if (!strcmp(this_opt, nocrtc))
+ nocrtc = 1;
+ else if (!strcmp(this_opt, noedid))
+ noedid = 1;
+ else if (!strcmp(this_opt, noblank))
+ blank = 0;
+ else if (!strncmp(this_opt, vtotal:, 7))
+ vram_total = simple_strtoul(this_opt + 7, NULL, 0);
+ else if (!strncmp(this_opt, vremap:, 7))
+ vram_remap = simple_strtoul(this_opt + 7, NULL, 0);
+ else if (!strncmp(this_opt, maxhf:, 6))
+ maxhf = simple_strtoul(this_opt + 6, NULL, 0);
+ else if (!strncmp(this_opt, maxvf:, 6))
+ maxvf = simple_strtoul(this_opt + 6, NULL, 0);
+ else if (!strncmp(this_opt, maxclk:, 7))
+ maxclk = simple_strtoul(this_opt + 7, NULL, 0);
+ else if (!strncmp(this_opt, vbemode:, 8))
+ vbemode = simple_strtoul(this_opt + 8, NULL,0);
+ else if (this_opt[0] = '0' this_opt[0] = '9') {
+ mode_option = this_opt;
+ } else {
+ printk(KERN_WARNING
+ uvesafb: unrecognized option %s\n, this_opt);
+ }
+ }
+
+ return 0;
+}
+#endif /* !MODULE */
The #ifdef MODULE is unpleasing. Can we use module_param() here? That'll
work for both modular and non-modular case.
True, but it would also make uvesafb the only (?) fb driver that
doesn't support the video=smthfb:options way of setting options.
Unless
[PATCH] fbcon: don't draw cursor when it's disabled
From: Michal Januszewski <[EMAIL PROTECTED]> When the cursor and echo are disabled on the current console, pressing a key will cause a black rectangle to be painted in the cursor's position. Fix this by not touching the framebuffer in fbcon_cursor() when the cursor is off. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- drivers/video/console/fbcon.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index f721341..7089aa8 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -1330,7 +1330,7 @@ static void fbcon_cursor(struct vc_data *vc, int mode) int y; int c = scr_readw((u16 *) vc->vc_pos); - if (fbcon_is_inactive(vc, info)) + if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1) return; ops->cursor_flash = (mode == CM_ERASE) ? 0 : 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/
[PATCH resend] vt: fix potential race in VT_WAITACTIVE handler
From: Michal Januszewski <[EMAIL PROTECTED]>
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen() but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
This is the 2nd version of this patch. It incorporates Andrew's
suggestions, ie. calls set_current_state() after down() and adds
a comment explaining why acquiring the console sem is necessary.
drivers/char/vt_ioctl.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 1fa2da8..0508293 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -1039,10 +1039,20 @@ int vt_waitactive(int vt)
add_wait_queue(_activate_queue, );
for (;;) {
- set_current_state(TASK_INTERRUPTIBLE);
retval = 0;
- if (vt == fg_console)
+
+ /* Synchronize with redraw_screen(). By acquiring the console
+* semaphore we make sure that the console switch is completed
+* before we return. If we didn't wait for the semaphore, we
+* could return at a point where fg_console has already been
+* updated, but the console switch hasn't been completed. */
+ acquire_console_sem();
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (vt == fg_console) {
+ release_console_sem();
break;
+ }
+ release_console_sem();
retval = -EINTR;
if (signal_pending(current))
break;
-
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/
[PATCH resend] vt: fix potential race in VT_WAITACTIVE handler
From: Michal Januszewski [EMAIL PROTECTED]
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen() but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
This is the 2nd version of this patch. It incorporates Andrew's
suggestions, ie. calls set_current_state() after down() and adds
a comment explaining why acquiring the console sem is necessary.
drivers/char/vt_ioctl.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 1fa2da8..0508293 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -1039,10 +1039,20 @@ int vt_waitactive(int vt)
add_wait_queue(vt_activate_queue, wait);
for (;;) {
- set_current_state(TASK_INTERRUPTIBLE);
retval = 0;
- if (vt == fg_console)
+
+ /* Synchronize with redraw_screen(). By acquiring the console
+* semaphore we make sure that the console switch is completed
+* before we return. If we didn't wait for the semaphore, we
+* could return at a point where fg_console has already been
+* updated, but the console switch hasn't been completed. */
+ acquire_console_sem();
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (vt == fg_console) {
+ release_console_sem();
break;
+ }
+ release_console_sem();
retval = -EINTR;
if (signal_pending(current))
break;
-
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/
[PATCH] fbcon: don't draw cursor when it's disabled
From: Michal Januszewski [EMAIL PROTECTED] When the cursor and echo are disabled on the current console, pressing a key will cause a black rectangle to be painted in the cursor's position. Fix this by not touching the framebuffer in fbcon_cursor() when the cursor is off. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- drivers/video/console/fbcon.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index f721341..7089aa8 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -1330,7 +1330,7 @@ static void fbcon_cursor(struct vc_data *vc, int mode) int y; int c = scr_readw((u16 *) vc-vc_pos); - if (fbcon_is_inactive(vc, info)) + if (fbcon_is_inactive(vc, info) || vc-vc_deccm != 1) return; ops-cursor_flash = (mode == CM_ERASE) ? 0 : 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/
[PATCH] vt: fix a potential race in the VT_WAITACTIVE handler
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen(), but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 3a5d301..00b5b34 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -1041,8 +1041,12 @@ int vt_waitactive(int vt)
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
retval = 0;
- if (vt == fg_console)
+ acquire_console_sem();
+ if (vt == fg_console) {
+ release_console_sem();
break;
+ }
+ release_console_sem();
retval = -EINTR;
if (signal_pending(current))
break;
-
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/
[PATCH] vt: fix a potential race in the VT_WAITACTIVE handler
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen(), but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 3a5d301..00b5b34 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -1041,8 +1041,12 @@ int vt_waitactive(int vt)
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
retval = 0;
- if (vt == fg_console)
+ acquire_console_sem();
+ if (vt == fg_console) {
+ release_console_sem();
break;
+ }
+ release_console_sem();
retval = -EINTR;
if (signal_pending(current))
break;
-
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/
[PATCH] fbdev: Update info->cmap when setting cmap from user-/kernelspace.
Hi.
The fb_info struct, as defined in include/linux/fb.h, contains an element
that is supposed to hold the current color map:
struct fb_cmap cmap;/* Current cmap */
This cmap is currently never updated when either fb_set_cmap() or
fb_set_user_cmap() are called. As a result, info->cmap contains the
default cmap that was set by a device driver/fbcon and a userspace
application using the FBIOGETCMAP ioctl will not always get the
*currently* used color map.
The patch fixes this by making sure the cmap is copied to info->cmap
after it is set correctly. It moves most of the code that is responsible
for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to
avoid code-duplication.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff -Nupr linux-2.6.12-orig/drivers/video/fbcmap.c
linux-2.6.12/drivers/video/fbcmap.c
--- linux-2.6.12-orig/drivers/video/fbcmap.c2005-06-17 21:48:29.0
+0200
+++ linux-2.6.12/drivers/video/fbcmap.c 2005-07-17 13:32:49.0 +0200
@@ -212,7 +212,7 @@ int fb_cmap_to_user(struct fb_cmap *from
int fb_set_cmap(struct fb_cmap *cmap, struct fb_info *info)
{
- int i, start;
+ int i, start, rc = 0;
u16 *red, *green, *blue, *transp;
u_int hred, hgreen, hblue, htransp = 0x;
@@ -225,75 +225,51 @@ int fb_set_cmap(struct fb_cmap *cmap, st
if (start < 0 || (!info->fbops->fb_setcolreg &&
!info->fbops->fb_setcmap))
return -EINVAL;
- if (info->fbops->fb_setcmap)
- return info->fbops->fb_setcmap(cmap, info);
- for (i = 0; i < cmap->len; i++) {
- hred = *red++;
- hgreen = *green++;
- hblue = *blue++;
- if (transp)
- htransp = *transp++;
- if (info->fbops->fb_setcolreg(start++,
- hred, hgreen, hblue, htransp,
- info))
- break;
+ if (info->fbops->fb_setcmap) {
+ rc = info->fbops->fb_setcmap(cmap, info);
+ } else {
+ for (i = 0; i < cmap->len; i++) {
+ hred = *red++;
+ hgreen = *green++;
+ hblue = *blue++;
+ if (transp)
+ htransp = *transp++;
+ if (info->fbops->fb_setcolreg(start++,
+ hred, hgreen, hblue,
+ htransp, info))
+ break;
+ }
}
- return 0;
+ if (rc == 0)
+ fb_copy_cmap(cmap, >cmap);
+
+ return rc;
}
int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
{
- int i, start;
- u16 __user *red, *green, *blue, *transp;
- u_int hred, hgreen, hblue, htransp = 0x;
-
- red = cmap->red;
- green = cmap->green;
- blue = cmap->blue;
- transp = cmap->transp;
- start = cmap->start;
-
- if (start < 0 || (!info->fbops->fb_setcolreg &&
- !info->fbops->fb_setcmap))
+ int rc, size = cmap->len * sizeof(u16);
+ struct fb_cmap umap;
+
+ if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
+ !info->fbops->fb_setcmap))
return -EINVAL;
- /* If we can batch, do it */
- if (info->fbops->fb_setcmap && cmap->len > 1) {
- struct fb_cmap umap;
- int size = cmap->len * sizeof(u16);
- int rc;
-
- memset(, 0, sizeof(struct fb_cmap));
- rc = fb_alloc_cmap(, cmap->len, transp != NULL);
- if (rc)
- return rc;
- if (copy_from_user(umap.red, red, size) ||
- copy_from_user(umap.green, green, size) ||
- copy_from_user(umap.blue, blue, size) ||
- (transp && copy_from_user(umap.transp, transp, size))) {
- rc = -EFAULT;
- }
- umap.start = start;
- if (rc == 0)
- rc = info->fbops->fb_setcmap(, info);
- fb_dealloc_cmap();
+ memset(, 0, sizeof(struct fb_cmap));
+ rc = fb_alloc_cmap(, cmap->len, cmap->transp != NULL);
+ if (rc)
return rc;
+ if (copy_from_user(umap.red, cmap->red, size) ||
+ copy_from_user(umap.green, cmap->green, size) ||
+ copy_from_user(umap.blue, cmap->blue, size) ||
+ (cmap->transp && copy_from_user(umap.transp, cmap->transp, size))) {
+
[PATCH][fbcon] Don't repaint the cursor when it is disabled.
Hi, Currently even when the cursor is disabled (`setterm -cursor off`), it is still repainted as a black rectangle the size of a single char. This can be seen, for example, by chvt'ing to a free tty, disabling the cursor and doing `dd if=/dev/urandom of=/dev/fb0`. The patch changes this behaviour by avoiding painting anything when the cursor is disabled. Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> --- diff -Nupr linux-2.6.12-orig/drivers/video/console/fbcon.c linux-2.6.12/drivers/video/console/fbcon.c --- linux-2.6.12-orig/drivers/video/console/fbcon.c 2005-06-17 21:48:29.0 +0200 +++ linux-2.6.12/drivers/video/console/fbcon.c 2005-07-17 13:32:00.0 +0200 @@ -276,7 +276,8 @@ static void fb_flashcursor(void *private if (!vc || !CON_IS_VISIBLE(vc) || fbcon_is_inactive(vc, info) || - registered_fb[con2fb_map[vc->vc_num]] != info) + registered_fb[con2fb_map[vc->vc_num]] != info || + vc_cons[ops->currcon].d->vc_deccm != 1) return; acquire_console_sem(); p = _display[vc->vc_num]; pgp8G2oTwa4GD.pgp Description: PGP signature
[PATCH][fbcon] Don't repaint the cursor when it is disabled.
Hi, Currently even when the cursor is disabled (`setterm -cursor off`), it is still repainted as a black rectangle the size of a single char. This can be seen, for example, by chvt'ing to a free tty, disabling the cursor and doing `dd if=/dev/urandom of=/dev/fb0`. The patch changes this behaviour by avoiding painting anything when the cursor is disabled. Signed-off-by: Michal Januszewski [EMAIL PROTECTED] --- diff -Nupr linux-2.6.12-orig/drivers/video/console/fbcon.c linux-2.6.12/drivers/video/console/fbcon.c --- linux-2.6.12-orig/drivers/video/console/fbcon.c 2005-06-17 21:48:29.0 +0200 +++ linux-2.6.12/drivers/video/console/fbcon.c 2005-07-17 13:32:00.0 +0200 @@ -276,7 +276,8 @@ static void fb_flashcursor(void *private if (!vc || !CON_IS_VISIBLE(vc) || fbcon_is_inactive(vc, info) || - registered_fb[con2fb_map[vc-vc_num]] != info) + registered_fb[con2fb_map[vc-vc_num]] != info || + vc_cons[ops-currcon].d-vc_deccm != 1) return; acquire_console_sem(); p = fb_display[vc-vc_num]; pgp8G2oTwa4GD.pgp Description: PGP signature
[PATCH] fbdev: Update info-cmap when setting cmap from user-/kernelspace.
Hi.
The fb_info struct, as defined in include/linux/fb.h, contains an element
that is supposed to hold the current color map:
struct fb_cmap cmap;/* Current cmap */
This cmap is currently never updated when either fb_set_cmap() or
fb_set_user_cmap() are called. As a result, info-cmap contains the
default cmap that was set by a device driver/fbcon and a userspace
application using the FBIOGETCMAP ioctl will not always get the
*currently* used color map.
The patch fixes this by making sure the cmap is copied to info-cmap
after it is set correctly. It moves most of the code that is responsible
for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to
avoid code-duplication.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff -Nupr linux-2.6.12-orig/drivers/video/fbcmap.c
linux-2.6.12/drivers/video/fbcmap.c
--- linux-2.6.12-orig/drivers/video/fbcmap.c2005-06-17 21:48:29.0
+0200
+++ linux-2.6.12/drivers/video/fbcmap.c 2005-07-17 13:32:49.0 +0200
@@ -212,7 +212,7 @@ int fb_cmap_to_user(struct fb_cmap *from
int fb_set_cmap(struct fb_cmap *cmap, struct fb_info *info)
{
- int i, start;
+ int i, start, rc = 0;
u16 *red, *green, *blue, *transp;
u_int hred, hgreen, hblue, htransp = 0x;
@@ -225,75 +225,51 @@ int fb_set_cmap(struct fb_cmap *cmap, st
if (start 0 || (!info-fbops-fb_setcolreg
!info-fbops-fb_setcmap))
return -EINVAL;
- if (info-fbops-fb_setcmap)
- return info-fbops-fb_setcmap(cmap, info);
- for (i = 0; i cmap-len; i++) {
- hred = *red++;
- hgreen = *green++;
- hblue = *blue++;
- if (transp)
- htransp = *transp++;
- if (info-fbops-fb_setcolreg(start++,
- hred, hgreen, hblue, htransp,
- info))
- break;
+ if (info-fbops-fb_setcmap) {
+ rc = info-fbops-fb_setcmap(cmap, info);
+ } else {
+ for (i = 0; i cmap-len; i++) {
+ hred = *red++;
+ hgreen = *green++;
+ hblue = *blue++;
+ if (transp)
+ htransp = *transp++;
+ if (info-fbops-fb_setcolreg(start++,
+ hred, hgreen, hblue,
+ htransp, info))
+ break;
+ }
}
- return 0;
+ if (rc == 0)
+ fb_copy_cmap(cmap, info-cmap);
+
+ return rc;
}
int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
{
- int i, start;
- u16 __user *red, *green, *blue, *transp;
- u_int hred, hgreen, hblue, htransp = 0x;
-
- red = cmap-red;
- green = cmap-green;
- blue = cmap-blue;
- transp = cmap-transp;
- start = cmap-start;
-
- if (start 0 || (!info-fbops-fb_setcolreg
- !info-fbops-fb_setcmap))
+ int rc, size = cmap-len * sizeof(u16);
+ struct fb_cmap umap;
+
+ if (cmap-start 0 || (!info-fbops-fb_setcolreg
+ !info-fbops-fb_setcmap))
return -EINVAL;
- /* If we can batch, do it */
- if (info-fbops-fb_setcmap cmap-len 1) {
- struct fb_cmap umap;
- int size = cmap-len * sizeof(u16);
- int rc;
-
- memset(umap, 0, sizeof(struct fb_cmap));
- rc = fb_alloc_cmap(umap, cmap-len, transp != NULL);
- if (rc)
- return rc;
- if (copy_from_user(umap.red, red, size) ||
- copy_from_user(umap.green, green, size) ||
- copy_from_user(umap.blue, blue, size) ||
- (transp copy_from_user(umap.transp, transp, size))) {
- rc = -EFAULT;
- }
- umap.start = start;
- if (rc == 0)
- rc = info-fbops-fb_setcmap(umap, info);
- fb_dealloc_cmap(umap);
+ memset(umap, 0, sizeof(struct fb_cmap));
+ rc = fb_alloc_cmap(umap, cmap-len, cmap-transp != NULL);
+ if (rc)
return rc;
+ if (copy_from_user(umap.red, cmap-red, size) ||
+ copy_from_user(umap.green, cmap-green, size) ||
+ copy_from_user(umap.blue, cmap-blue, size) ||
+ (cmap-transp copy_from_user(umap.transp, cmap-transp, size))) {
+ fb_dealloc_cmap(umap);
+ return -EFAULT;
}
-
- for (i = 0; i cmap-len; i++, red++, blue++, green++) {
- if (get_user(hred, red) ||
- get_user(hgreen, green) ||
- get_user(hblue, blue
Re: [announce 7/7] fbsplash - documentation
On Wed, Mar 09, 2005 at 04:40:09PM +0100, Arnd Bergmann wrote: > Ok, I now saw that you call call_usermodehelper with wait==1. Why is that > necessary? If you don't wait there, you don't need any hacks around the > console semaphore, because the helper will simply wait for change_console > to finish. That could work, assuming that: a) the helper can always finish unpacking the image before change_console releases the semaphore b) the console is not redrawn at one point before change_console is finished (I'm sorry, I don't have time to check that right now) If one of this assumptions is wrong, we would end up with first displaying the wrong background picture and then quickly painting the new one (I doubt this would make a good impression on the user..). > > What are the alternatives to the ioctl? A relatively clean way of > > feeding the data back to the kernel would be using sysfs. However, to > > make it sane we would have to export the various components of struct > > vc_splash in /sys/class/tty/tty (otherwise, we would probabky have > > to pass aggreaget data types through a sysfs entry -- something that is > > IMO much worse than an ioctl). That however could be a little > > problematic -- tty_class is currently defined as a class_simple. > > To add entries other than the standard 'dev' we would have to define a > > completely new class, right? That sounds like a rather intrusive > > change.. > > Right. I don't think that sysfs is the right interface for this problem. > For a short moment I had the idea that you could write an escape sequence > to the tty device, but that would race against the regular output. > An ioctl on the tty device is probably the best you can do here, but > if that's not possible, creating a misc device in order to do ioctl on it > is a rather ugly hack. Agreed, that might not be the nicest thing to do, but it just seems there isn't much of a choice in this situation. I'm going to be away for the next 10 days or so. When I get back I'll start testing some of the proposed changes. Maybe by using things like firmware_request it would at least be possible to make the splash interface a little simpler. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpirYyFTnfy2.pgp Description: PGP signature
Re: [announce 7/7] fbsplash - documentation
On Wed, Mar 09, 2005 at 04:40:09PM +0100, Arnd Bergmann wrote: Ok, I now saw that you call call_usermodehelper with wait==1. Why is that necessary? If you don't wait there, you don't need any hacks around the console semaphore, because the helper will simply wait for change_console to finish. That could work, assuming that: a) the helper can always finish unpacking the image before change_console releases the semaphore b) the console is not redrawn at one point before change_console is finished (I'm sorry, I don't have time to check that right now) If one of this assumptions is wrong, we would end up with first displaying the wrong background picture and then quickly painting the new one (I doubt this would make a good impression on the user..). What are the alternatives to the ioctl? A relatively clean way of feeding the data back to the kernel would be using sysfs. However, to make it sane we would have to export the various components of struct vc_splash in /sys/class/tty/ttyx (otherwise, we would probabky have to pass aggreaget data types through a sysfs entry -- something that is IMO much worse than an ioctl). That however could be a little problematic -- tty_class is currently defined as a class_simple. To add entries other than the standard 'dev' we would have to define a completely new class, right? That sounds like a rather intrusive change.. Right. I don't think that sysfs is the right interface for this problem. For a short moment I had the idea that you could write an escape sequence to the tty device, but that would race against the regular output. An ioctl on the tty device is probably the best you can do here, but if that's not possible, creating a misc device in order to do ioctl on it is a rather ugly hack. Agreed, that might not be the nicest thing to do, but it just seems there isn't much of a choice in this situation. I'm going to be away for the next 10 days or so. When I get back I'll start testing some of the proposed changes. Maybe by using things like firmware_request it would at least be possible to make the splash interface a little simpler. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpirYyFTnfy2.pgp Description: PGP signature
Re: [announce 7/7] fbsplash - documentation
On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote: > You also shouldn't create a class device every time you want to call > kobject_hotplug. Note that every character device already has a class > device associated with it, so you might be able to just use that to > call kobject_hotplug on it. > > If there is no obvious way to do that, just leave the code as it is > for calling the helper. OK, thanks forthe explanation and advice. I'll look into it. > > The reason for calling init in that place is the ability to use the > > userspace helper to display a nice picture while the kernel is still > > loading. Sure, you can just drop it and use the 'quiet' command line > > option, but that will give you a black screen for a good few seconds. > > And people who want eye-candy like fbsplash generally don't like > > that. > > Ok, understood. I think you should make that an extra patch and completely > remove that feature from the base patchset in order to make it less > controversial. That can be done. The funny thing is, a week ago or so, it was proposed in a thread about bootsplash that the code for the initial call could be merged first and serve as a base for merging fbsplash :) > > > That sounds really dangerous. Can you guarantee that nothing > > > unexpected happens when a malicious user calls the ioctls with > > > FB_SPLASH_IO_ORIG_KERNEL from a regular user process? > > > > This is pretty nasty, right, but I just can't see a way around it. > > The thing is, when the splash helper is called from the kernel, the > > console semaphore is already held so we have to avoid trying to acquire > > it again. And we can't just release it prior to calling the helper, as > > it would break things badly. > > I don't understand. Does the kernel code need to wait for the helper > to finish while holding the semaphore? AFAICS, the helper is > completely asynchronous, so it can simply do its job when the kernel > has given up the semaphore. > > And we can't do ioctls on ttys when > > answering a kernel request because to the console sem problems > > (opening a tty = a call to acquire_console_sem(), which we need to > > avoid). > > Hmm. One of us has misunderstood the interaction between > call_usermodehelper() and acquire_console_sem(). If I'm the one > who's wrong, please tell me where that semaphore is held. It think this will be best explained with an example. Consider the following situation - we have two ttys - tty1 and tty2. tty1 is using theme 'foo' an it's the foreground console. tty2 is using theme 'bar'. Fbsplash is enabled on both these ttys. Now the user decides to switch to tty2. He/she presses Alt+F2. The keypress is handled somewhere and an item is added to the console_work workqueue. console_callback() gets called asynchronously. acquire_console_sem() is the first thing done in that function. Now we have the following call stack (all done with the console sem held): change_console() complete_change_console() switch_screen() == redraw_screen() con_switch() == fbcon_switch() From inside fbcon_switch(), we need to call the splash helper to get a new picture for the theme 'bar' which is used on tty2. The splash helper does an ioctl and we're back in the kernel.. with the console semaphore already held. > > The original idea behind this was to group the fields that are > > common to all fbsplash ioctl calls (ie. vc and origin) in one place. > > Of course, it can be changed to three differents structs, each > > containing the vc and origin fields and an int/struct vc_splash/struct > > fb_image, if that is the preferred way of doing things. > > It definitely is. Actually, it would be preferred to have only a > single value as ioctl argument (or even better, no ioctl at all), > but if you need to pass an aggregate data type, it should at least > have an identical layout for all architectures. That means every > member should be naturally aligned and you can't use pointers or other > types that have sizeof(x) == sizeof(long). What are the alternatives to the ioctl? A relatively clean way of feeding the data back to the kernel would be using sysfs. However, to make it sane we would have to export the various components of struct vc_splash in /sys/class/tty/tty (otherwise, we would probabky have to pass aggreaget data types through a sysfs entry -- something that is IMO much worse than an ioctl). That however could be a little problematic -- tty_class is currently defined as a class_simple. To add entries other than the standard 'dev' we would have to define a completely new class, right? That sounds like a rather intrusive change.. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpdoH5LwDpT0.pgp Description: PGP signature
Re: [announce 7/7] fbsplash - documentation
On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote: > It should probably just use its own hotplug agent instead of calling > the helper directly. I've just had a look at it, and it seems possible. From what I have seen in the firmware_class.c code, it would require: - registering a class somewhere in the initializaton code - every time a request from fbcon is generated: - register the class device - create a timer - call kobject_hotplug() to send the event to userspace - unregister the device This requests sent to userspace are generated while switching consoles and resetting the graphics mode. This whole create device - send the event - remove device thing seems a little long to me. Would it be acceptable? > > +Splash protocol v1 specified an additional 'fbsplash mode' after the > > +framebuffer number. Splash protocol v1 is deprecated and should not be > > used. > When you're submitting a patch for inclusion, the interface should really > be stable. I'd completely drop all references to the old version and only > support one interface here. Moreover, you should not do versioned interfaces The old one is already not supported. I mentioned v1 in the docs only so that it would be clear where do the '2' in the helper's command line arguments come from. > unless you expect incompatible changes in future releases. As long as you > still do, that is a sign that the patch is not ready for inclusion. I don't do now, but who knows when changes will be made to fbcon in the future? There's a possibility that things will change enough to justify a new splash protocol. On the other hand, if the hotplug way of calling userspace were to be adopted in fbsplash, the whole splash interface with the versioning scheme could be dropped, which, I guess, would be a good thing. > > + When the userspace helper is called in an early phase of the boot process > > + (right after the initialization of fbcon), no filesystems will be mounted. > > + The helper program should mount sysfs and then create the appropriate > > + framebuffer, fbsplash and tty0 devices (if they don't already exist) to > > get > > + current display settings and to be able to communicate with the kernel > > side. > > + It should probably also mount the procfs to be able to parse the kernel > > + command line parameters. > Nothing about the init command seems really necessary. Why not just do > that stuff from an /sbin/init script? The reason for calling init in that place is the ability to use the userspace helper to display a nice picture while the kernel is still loading. Sure, you can just drop it and use the 'quiet' command line option, but that will give you a black screen for a good few seconds. And people who want eye-candy like fbsplash generally don't like that. I'm currently using a setup that is a combination of both the 'quiet' option and the 'init' command. I'm using the splash helper to switch to a selected tty and display a full-screen image, while keeping the tty in KD_TEXT. This looks pretty nice and lets me see the initial bitmap for ca. 5 secs. > > +FB_SPLASH_IO_ORIG_KERNEL instructs fbsplash not to try to acquire the > > console > > +semaphore. Not surprisingly, FB_SPLASH_IO_ORIG_USER instructs it to acquire > > +the console sem. > > That sounds really dangerous. Can you guarantee that nothing unexpected > happens > when a malicious user calls the ioctls with FB_SPLASH_IO_ORIG_KERNEL from a > regular user process? This is pretty nasty, right, but I just can't see a way around it. The thing is, when the splash helper is called from the kernel, the console semaphore is already held so we have to avoid trying to acquire it again. And we can't just release it prior to calling the helper, as it would break things badly. To make sure no one uses fbsplash for malicious purposes, the /dev/fbsplash device is used, which is kept root-writable only. > > +Info on used structures: > > + > > +Definition of struct vc_splash can be found in linux/console_splash.h. It's > > +heavily commented. Note that the 'theme' field should point to a string > Not that heavily documented, actually ;-). Anything that needs some clearing-up? > > +no longer than FB_SPLASH_THEME_LEN. When FBIOSPLASH_GETCFG call is > > +performed, the theme field should point to a char buffer of length > > +FB_SPLASH_THEME_LEN. > Then don't make it pointer but instead a field of that length. Pointers > in ioctl arguments only cause trouble in mixed 32/64 bit environments. That could be arranged, but this would require a separate structure for communicating with userspace and with in-kernel data storage (currently both these tasks are handled with struct vc_splash), or changing vc_splash in vc_data to a pointer to a structure. The latter option would be better I think. > > +Definition of struct fb_splash_iowrapper can be found in linux/fb.h. > > +The fields in this struct have the following meaning: > > + > > +vc: > > +Virtual
Re: [announce 7/7] fbsplash - documentation
On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote: It should probably just use its own hotplug agent instead of calling the helper directly. I've just had a look at it, and it seems possible. From what I have seen in the firmware_class.c code, it would require: - registering a class somewhere in the initializaton code - every time a request from fbcon is generated: - register the class device - create a timer - call kobject_hotplug() to send the event to userspace - unregister the device This requests sent to userspace are generated while switching consoles and resetting the graphics mode. This whole create device - send the event - remove device thing seems a little long to me. Would it be acceptable? +Splash protocol v1 specified an additional 'fbsplash mode' after the +framebuffer number. Splash protocol v1 is deprecated and should not be used. When you're submitting a patch for inclusion, the interface should really be stable. I'd completely drop all references to the old version and only support one interface here. Moreover, you should not do versioned interfaces The old one is already not supported. I mentioned v1 in the docs only so that it would be clear where do the '2' in the helper's command line arguments come from. unless you expect incompatible changes in future releases. As long as you still do, that is a sign that the patch is not ready for inclusion. I don't do now, but who knows when changes will be made to fbcon in the future? There's a possibility that things will change enough to justify a new splash protocol. On the other hand, if the hotplug way of calling userspace were to be adopted in fbsplash, the whole splash interface with the versioning scheme could be dropped, which, I guess, would be a good thing. + When the userspace helper is called in an early phase of the boot process + (right after the initialization of fbcon), no filesystems will be mounted. + The helper program should mount sysfs and then create the appropriate + framebuffer, fbsplash and tty0 devices (if they don't already exist) to get + current display settings and to be able to communicate with the kernel side. + It should probably also mount the procfs to be able to parse the kernel + command line parameters. Nothing about the init command seems really necessary. Why not just do that stuff from an /sbin/init script? The reason for calling init in that place is the ability to use the userspace helper to display a nice picture while the kernel is still loading. Sure, you can just drop it and use the 'quiet' command line option, but that will give you a black screen for a good few seconds. And people who want eye-candy like fbsplash generally don't like that. I'm currently using a setup that is a combination of both the 'quiet' option and the 'init' command. I'm using the splash helper to switch to a selected tty and display a full-screen image, while keeping the tty in KD_TEXT. This looks pretty nice and lets me see the initial bitmap for ca. 5 secs. +FB_SPLASH_IO_ORIG_KERNEL instructs fbsplash not to try to acquire the console +semaphore. Not surprisingly, FB_SPLASH_IO_ORIG_USER instructs it to acquire +the console sem. That sounds really dangerous. Can you guarantee that nothing unexpected happens when a malicious user calls the ioctls with FB_SPLASH_IO_ORIG_KERNEL from a regular user process? This is pretty nasty, right, but I just can't see a way around it. The thing is, when the splash helper is called from the kernel, the console semaphore is already held so we have to avoid trying to acquire it again. And we can't just release it prior to calling the helper, as it would break things badly. To make sure no one uses fbsplash for malicious purposes, the /dev/fbsplash device is used, which is kept root-writable only. +Info on used structures: + +Definition of struct vc_splash can be found in linux/console_splash.h. It's +heavily commented. Note that the 'theme' field should point to a string Not that heavily documented, actually ;-). Anything that needs some clearing-up? +no longer than FB_SPLASH_THEME_LEN. When FBIOSPLASH_GETCFG call is +performed, the theme field should point to a char buffer of length +FB_SPLASH_THEME_LEN. Then don't make it pointer but instead a field of that length. Pointers in ioctl arguments only cause trouble in mixed 32/64 bit environments. That could be arranged, but this would require a separate structure for communicating with userspace and with in-kernel data storage (currently both these tasks are handled with struct vc_splash), or changing vc_splash in vc_data to a pointer to a structure. The latter option would be better I think. +Definition of struct fb_splash_iowrapper can be found in linux/fb.h. +The fields in this struct have the following meaning: + +vc: +Virtual console number. This should not be needed. I notice you are creating
Re: [announce 7/7] fbsplash - documentation
On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote: You also shouldn't create a class device every time you want to call kobject_hotplug. Note that every character device already has a class device associated with it, so you might be able to just use that to call kobject_hotplug on it. If there is no obvious way to do that, just leave the code as it is for calling the helper. OK, thanks forthe explanation and advice. I'll look into it. The reason for calling init in that place is the ability to use the userspace helper to display a nice picture while the kernel is still loading. Sure, you can just drop it and use the 'quiet' command line option, but that will give you a black screen for a good few seconds. And people who want eye-candy like fbsplash generally don't like that. Ok, understood. I think you should make that an extra patch and completely remove that feature from the base patchset in order to make it less controversial. That can be done. The funny thing is, a week ago or so, it was proposed in a thread about bootsplash that the code for the initial call could be merged first and serve as a base for merging fbsplash :) That sounds really dangerous. Can you guarantee that nothing unexpected happens when a malicious user calls the ioctls with FB_SPLASH_IO_ORIG_KERNEL from a regular user process? This is pretty nasty, right, but I just can't see a way around it. The thing is, when the splash helper is called from the kernel, the console semaphore is already held so we have to avoid trying to acquire it again. And we can't just release it prior to calling the helper, as it would break things badly. I don't understand. Does the kernel code need to wait for the helper to finish while holding the semaphore? AFAICS, the helper is completely asynchronous, so it can simply do its job when the kernel has given up the semaphore. And we can't do ioctls on ttys when answering a kernel request because to the console sem problems (opening a tty = a call to acquire_console_sem(), which we need to avoid). Hmm. One of us has misunderstood the interaction between call_usermodehelper() and acquire_console_sem(). If I'm the one who's wrong, please tell me where that semaphore is held. It think this will be best explained with an example. Consider the following situation - we have two ttys - tty1 and tty2. tty1 is using theme 'foo' an it's the foreground console. tty2 is using theme 'bar'. Fbsplash is enabled on both these ttys. Now the user decides to switch to tty2. He/she presses Alt+F2. The keypress is handled somewhere and an item is added to the console_work workqueue. console_callback() gets called asynchronously. acquire_console_sem() is the first thing done in that function. Now we have the following call stack (all done with the console sem held): change_console() complete_change_console() switch_screen() == redraw_screen() con_switch() == fbcon_switch() From inside fbcon_switch(), we need to call the splash helper to get a new picture for the theme 'bar' which is used on tty2. The splash helper does an ioctl and we're back in the kernel.. with the console semaphore already held. The original idea behind this was to group the fields that are common to all fbsplash ioctl calls (ie. vc and origin) in one place. Of course, it can be changed to three differents structs, each containing the vc and origin fields and an int/struct vc_splash/struct fb_image, if that is the preferred way of doing things. It definitely is. Actually, it would be preferred to have only a single value as ioctl argument (or even better, no ioctl at all), but if you need to pass an aggregate data type, it should at least have an identical layout for all architectures. That means every member should be naturally aligned and you can't use pointers or other types that have sizeof(x) == sizeof(long). What are the alternatives to the ioctl? A relatively clean way of feeding the data back to the kernel would be using sysfs. However, to make it sane we would have to export the various components of struct vc_splash in /sys/class/tty/ttyx (otherwise, we would probabky have to pass aggreaget data types through a sysfs entry -- something that is IMO much worse than an ioctl). That however could be a little problematic -- tty_class is currently defined as a class_simple. To add entries other than the standard 'dev' we would have to define a completely new class, right? That sounds like a rather intrusive change.. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpdoH5LwDpT0.pgp Description: PGP signature
Re: Bootsplash for 2.6.11-rc4
On Sun, Feb 27, 2005 at 01:03:33PM -0800, Greg KH wrote: > Care to create a patch for the silent mode now? That should be simple > enough to get into the kernel, and will be a good place to build off of > for the rest of the things people want (verbose mode, etc.) I've just sent the whole thing split up into seven parts. After working on both fbsplash and splashutils for the last few days, I came to the conclusion that the initial silent mode patch wouldn't make much sense (it would create a short fbsplash.c file with a single call to call_usermodehelper()) and the whole splash interface thing would completely pointless. I tried to move as much as possible into userspace. If anyone can find away to move more code to the userspace, please let me know -- I'd be glad to make fbsplash even lighter :) Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpYPIhWrKKqr.pgp Description: PGP signature
[announce 4/7] fbsplash - fbcon updates
Updates to fbcon.c. Kept as non-intrusive as possible.
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]>
---
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c 2005-03-07 16:50:34 +01:00
+++ b/drivers/video/console/fbcon.c 2005-03-07 16:50:34 +01:00
@@ -93,6 +93,7 @@
#endif
#include "fbcon.h"
+#include "../fbsplash.h"
#ifdef FBCONDEBUG
# define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ ,
## args)
@@ -206,7 +207,7 @@
vt_cons[vc->vc_num]->vc_mode != KD_TEXT);
}
-static inline int get_color(struct vc_data *vc, struct fb_info *info,
+inline int get_color(struct vc_data *vc, struct fb_info *info,
u16 c, int is_fg)
{
int depth = fb_get_color_depth(info);
@@ -270,7 +271,8 @@
if (!vc || !CON_IS_VISIBLE(vc) ||
fbcon_is_inactive(vc, info) ||
- registered_fb[con2fb_map[vc->vc_num]] != info)
+ registered_fb[con2fb_map[vc->vc_num]] != info ||
+ vc_cons[ops->currcon].d->vc_deccm != 1)
return;
acquire_console_sem();
p = _display[vc->vc_num];
@@ -279,6 +281,7 @@
CM_ERASE : CM_DRAW;
ops->cursor(vc, info, p, mode, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
+
release_console_sem();
}
@@ -404,6 +407,8 @@
info_idx = -1;
}
+ fbsplash_init();
+
return err;
}
@@ -802,6 +807,12 @@
cols = info->var.xres / vc->vc_font.width;
rows = info->var.yres / vc->vc_font.height;
+
+ if (fbsplash_active(info, vc)) {
+ cols = vc->vc_splash.twidth / vc->vc_font.width;
+ rows = vc->vc_splash.theight / vc->vc_font.height;
+ }
+
vc_resize(vc->vc_num, cols, rows);
DPRINTK("mode: %s\n", info->fix.id);
@@ -897,7 +908,7 @@
if (info_idx == -1 || info == NULL)
return;
if (vc->vc_num != display_fg || logo_shown == FBCON_LOGO_DONTSHOW ||
- (info->fix.type == FB_TYPE_TEXT))
+ (info->fix.type == FB_TYPE_TEXT) || fbsplash_active(info, vc))
logo = 0;
info->var.xoffset = info->var.yoffset = p->yscroll = 0; /* reset
wrap/pan */
@@ -1038,6 +1049,11 @@
if (!height || !width)
return;
+ if (fbsplash_active(info, vc)) {
+ fbsplash_clear(vc, info, sy, sx, height, width);
+ return;
+ }
+
/* Split blits that cross physical y_wrap boundary */
y_break = p->vrows - p->yscroll;
@@ -1057,10 +1073,15 @@
struct display *p = _display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
- if (!fbcon_is_inactive(vc, info))
- ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
- get_color(vc, info, scr_readw(s), 1),
- get_color(vc, info, scr_readw(s), 0));
+ if (!fbcon_is_inactive(vc, info)) {
+
+ if (fbsplash_active(info, vc))
+ fbsplash_putcs(vc, info, s, count, ypos, xpos);
+ else
+ ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
+ get_color(vc, info, scr_readw(s), 1),
+ get_color(vc, info, scr_readw(s), 0));
+ }
}
static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
@@ -1076,8 +1097,13 @@
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
struct fbcon_ops *ops = info->fbcon_par;
- if (!fbcon_is_inactive(vc, info))
- ops->clear_margins(vc, info, bottom_only);
+ if (!fbcon_is_inactive(vc, info)) {
+ if (fbsplash_active(info, vc)) {
+ fbsplash_clear_margins(vc, info, bottom_only);
+ } else {
+ ops->clear_margins(vc, info, bottom_only);
+ }
+ }
}
static void fbcon_cursor(struct vc_data *vc, int mode)
@@ -1560,7 +1586,7 @@
count = vc->vc_rows;
if (softback_top)
fbcon_softback_note(vc, t, count);
- if (logo_shown >= 0)
+ if (logo_shown >= 0 || fbsplash_active(info, vc))
goto redraw_up;
switch (p->scrollmode) {
case SCROLL_MOVE:
@@ -1646,6 +1672,8 @@
case SM_DOWN:
if (count > vc->vc_rows)/* Maximum realistic size */
count = vc->vc_rows;
+ if (fbsplash_active(info, vc))
+ goto redraw_down;
switch (p->scrollmode) {
case SCROLL_MOVE:
ops->bmove(vc, info, t, 0, t + count, 0,
@@ -1788,6 +1816,13 @@
}
return;
}
+
+ if (fbsplash_active(info, vc)
[announce 7/7] fbsplash - documentation
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]> --- diff -Nru a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX --- a/Documentation/fb/00-INDEX 2005-03-07 16:50:34 +01:00 +++ b/Documentation/fb/00-INDEX 2005-03-07 16:50:34 +01:00 @@ -19,6 +19,8 @@ - info on the Matrox frame buffer driver pvr2fb.txt - info on the PowerVR 2 frame buffer driver +splash.txt + - info on the Framebuffer Splash tgafb.txt - info on the TGA (DECChip 21030) frame buffer driver vesafb.txt diff -Nru a/Documentation/fb/splash.txt b/Documentation/fb/splash.txt --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/fb/splash.txt 2005-03-07 16:50:34 +01:00 @@ -0,0 +1,207 @@ +What is it? +--- + +The framebuffer splash is a kernel feature that allows displaying a background +picture on selected consoles. + +What do I need to get it to work? +- + +To get fb splash up-and-running you will have to: + 1) get a copy of splashutils [1] or a similar program + 2) get some splash themes + 3) build the kernel helper program + 4) build your kernel with the FB_SPLASH option enabled. + +To get fb splash operational right after fbcon initialization is finished, you +will have to include a theme and the kernel helper into your initramfs image. +Please refer to splashutils documentation for instructions on how to do that. + +[1] The splashutils package can be downloaded from: +http://dev.gentoo.org/~spock/projects/splashutils/ + +The userspace helper + + +The userspace splash helper (by default: /sbin/splash_helper) is called by the +kernel whenever an important event occurs and the kernel needs some kind of +job to be carried out. Important events include console switches and graphic +mode switches (the kernel requests background images and configuration +parameters for the current console). The splash helper must be accessible at +all times. If it's not, fbsplash will be switched off automatically. + +It's possible to set path to the splash helper by writing it to +/proc/sys/kernel/fbsplash. + +* + +The information below is mostly technical stuff. There's probably no need to +read it unless you plan to develop a userspace helper. + +The splash protocol +--- + +The splash protocol defines a communication interface between the kernel and +the userspace splash helper. + +The kernel side is responsible for: + + o rendering console text, using an image as a background (instead of a + standard solid color fbcon uses), + o accepting commands from the user via ioctls on the fbsplash device, + o calling the userspace helper to set things up as soon as the fb subsystem + is initialized. + +The userspace helper is responsible for everything else, including parsing +configuration files, decompressing the image files whenever the kernel needs +it, and communicating with the kernel if necessary. + +The splash protocol specifies how communication is done in both ways: +kernel->userspace and userspace->helper. + +Kernel -> Userspace +--- + +The kernel communicates with the userspace helper by calling it and specifying +the task to be done in a series of arguments. + +The arguments follow the pattern: + + +All commands defined in splash protocol v2 have the following parameters: + virtual console + framebuffer number + theme + +Splash protocol v1 specified an additional 'fbsplash mode' after the +framebuffer number. Splash protocol v1 is deprecated and should not be used. + +Splash protocol v2 specifies the following commands: + +getpic +-- + The kernel issues this command to request image data. It's up to the userspace + helper to find a background image appropriate for the specified theme and the + current resolution. The userspace helper should respond by issuing the + FBIOSPLASH_SETPIC ioctl. + +init + + The kernel issues this command after the fbsplash device is created and + the fbsplash interface is initialized. Upon receiving 'init', the userspace + helper should parse the kernel command line (/proc/cmdline) or otherwise + decide whether fbsplash is to be activated. + + To activate fbsplash on the first console the helper should issue the + FBIOSPLASH_SETCFG, FBIOSPLASH_SETPIC and FBIOSPLASH_SETSTATE commands, + in the above-mentioned order. + + When the userspace helper is called in an early phase of the boot process + (right after the initialization of fbcon), no filesystems will be mounted. + The helper program should mount sysfs and then create the appropriate + framebuffer, fbsplash and tty0 devices (if they don't already exist) to get + current display settings and to be able to communicate with the kernel side. + It should probably also mount the procfs to be able to parse the kernel + command line parameters. + + Note that the console sem is not held when the kernel calls splash_helper + with the
[announce 6/7] fbsplash - kconfig and makefiles
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]> --- diff -Nru a/drivers/video/Kconfig b/drivers/video/Kconfig --- a/drivers/video/Kconfig 2005-03-07 16:50:34 +01:00 +++ b/drivers/video/Kconfig 2005-03-07 16:50:34 +01:00 @@ -1140,5 +1140,15 @@ source "drivers/video/backlight/Kconfig" endif -endmenu +config FB_SPLASH + bool "Support for the framebuffer splash" + depends on FRAMEBUFFER_CONSOLE=y && !FB_TILEBLITTING + default n + ---help--- + This option enables support for graphical backgrounds on consoles. + Note that you will need userspace splash utilities in order to take + advantage of these features. Refer to Documentation/fb/splash.txt + for more information. + If unsure, say N. +endmenu diff -Nru a/drivers/Makefile b/drivers/Makefile --- a/drivers/Makefile 2005-03-07 16:50:34 +01:00 +++ b/drivers/Makefile 2005-03-07 16:50:34 +01:00 @@ -7,15 +7,14 @@ obj-$(CONFIG_PCI) += pci/ obj-$(CONFIG_PARISC) += parisc/ +# char/ comes before serial/ etc so that the VT console is the boot-time +# default. +obj-y += char/ obj-y += video/ obj-$(CONFIG_ACPI_BOOT)+= acpi/ # PnP must come after ACPI since it will eventually need to check if acpi # was used and do nothing if so obj-$(CONFIG_PNP) += pnp/ - -# char/ comes before serial/ etc so that the VT console is the boot-time -# default. -obj-y += char/ # i810fb and intelfb depend on char/agp/ obj-$(CONFIG_FB_I810) += video/i810/ diff -Nru a/drivers/video/Makefile b/drivers/video/Makefile --- a/drivers/video/Makefile2005-03-07 16:50:34 +01:00 +++ b/drivers/video/Makefile2005-03-07 16:50:34 +01:00 @@ -7,6 +7,7 @@ obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-$(CONFIG_SYSFS) += backlight/ +obj-$(CONFIG_FB_SPLASH) += fbsplash.o cfbsplash.o obj-$(CONFIG_FB) += fbmem.o fbmon.o fbcmap.o fbsysfs.o modedb.o softcursor.o # Only include macmodes.o if we have FB support and are PPC - 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/
[announce 5/7] fbsplash - fbdev updates
Fbcmap.c updates. Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]> --- diff -Nru a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c --- a/drivers/video/fbcmap.c2005-03-07 16:50:34 +01:00 +++ b/drivers/video/fbcmap.c2005-03-07 16:50:34 +01:00 @@ -16,6 +16,7 @@ #include #include #include +#include "fbsplash.h" #include @@ -235,6 +236,10 @@ info)) break; } + fb_copy_cmap(cmap, >cmap); + if (fbsplash_active(info, vc_cons[fg_console].d) && + info->fix.visual == FB_VISUAL_DIRECTCOLOR) + fbsplash_fix_pseudo_pal(info, vc_cons[fg_console].d); return 0; } @@ -265,6 +270,9 @@ if (transp) transp++; } + if (fbsplash_active(info, vc_cons[fg_console].d) && + info->fix.visual == FB_VISUAL_DIRECTCOLOR) + fbsplash_fix_pseudo_pal(info, vc_cons[fg_console].d); return 0; } Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl - 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/
[announce 2/7] fbsplash - rendering routines
Fbsplash has its own set of rendering functions. These are
unaccelerated but they should work with different framebuffer drivers.
All rendering routines are completely separate from fbcon.
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]>
---
diff -Nru a/drivers/video/cfbsplash.c b/drivers/video/cfbsplash.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/video/cfbsplash.c 2005-03-07 16:50:34 +01:00
@@ -0,0 +1,468 @@
+/*
+ * linux/drivers/video/cfbsplash.c -- Framebuffer splash rendering functions
+ *
+ * Copyright (C) 2004-2005 Michael Januszewski <[EMAIL PROTECTED]>
+ *
+ * Code based upon "Bootsplash" (C) 2001-2003
+ * Volker Poplawski <[EMAIL PROTECTED]>,
+ * Stefan Reinauer <[EMAIL PROTECTED]>,
+ * Steffen Winterfeldt <[EMAIL PROTECTED]>,
+ * Michael Schroeder <[EMAIL PROTECTED]>,
+ * Ken Wimer <[EMAIL PROTECTED]>.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "console/fbcon.h"
+#include "fbsplash.h"
+
+#define parse_pixel(shift,bpp,type)
\
+ do {
\
+ if (d & (0x80 >> (shift)))
\
+ dd2[(shift)] = fgx;
\
+ else
\
+ dd2[(shift)] = transparent ? *(type *)splash_src : bgx;
\
+ splash_src += (bpp);
\
+ } while (0)
\
+
+extern int get_color(struct vc_data *vc, struct fb_info *info,
+u16 c, int is_fg);
+
+void fbsplash_fix_pseudo_pal(struct fb_info *info, struct vc_data *vc)
+{
+ int i, j, k;
+ int minlen = min(min(info->var.red.length, info->var.green.length),
+info->var.blue.length);
+ u32 col;
+
+ for (j = i = 0; i < 16; i++) {
+ k = color_table[i];
+
+ col = ((vc->vc_palette[j++] >> (8-minlen))
+ << info->var.red.offset);
+ col |= ((vc->vc_palette[j++] >> (8-minlen))
+ << info->var.green.offset);
+ col |= ((vc->vc_palette[j++] >> (8-minlen))
+ << info->var.blue.offset);
+ ((u32 *)info->pseudo_palette)[k] = col;
+ }
+}
+
+void fbsplash_renderc(struct fb_info *info, int ypos, int xpos, int height,
+ int width, u8* src, u32 fgx, u32 bgx, u8 transparent)
+{
+ unsigned int x, y;
+ u32 dd;
+ int bytespp = ((info->var.bits_per_pixel + 7) >> 3);
+ unsigned int d = ypos * info->fix.line_length + xpos * bytespp;
+ unsigned int ds = (ypos * info->var.xres + xpos) * bytespp;
+ u16 dd2[4];
+
+ u8* splash_src = (u8 *)(info->splash.data + ds);
+ u8* dst = (u8 *)(info->screen_base + d);
+
+ if ((ypos + height) > info->var.yres || (xpos + width) > info->var.xres)
+ return;
+
+ for (y = 0; y < height; y++) {
+ switch (info->var.bits_per_pixel) {
+
+ case 32:
+ for (x = 0; x < width; x++) {
+
+ if ((x & 7) == 0)
+ d = *src++;
+ if (d & 0x80)
+ dd = fgx;
+ else
+ dd = transparent ?
+*(u32 *)splash_src : bgx;
+
+ d <<= 1;
+ splash_src += 4;
+ fb_writel(dd, dst);
+ dst += 4;
+ }
+ break;
+ case 24:
+ for (x = 0; x < width; x++) {
+
+ if ((x & 7) == 0)
+ d = *src++;
+ if (d & 0x80)
+ dd = fgx;
+ else
+ dd = transparent ?
+(*(u32 *)splash_src & 0xff) :
bgx;
+
+ d <<= 1;
+ splash_src += 3;
+#ifdef __LITTLE_ENDIAN
+ fb_writew(dd & 0x, dst);
+ dst += 2;
+
[announce 3/7] fbsplash - data structures
Fbsplash uses a special iowrapper struct for communication with
userspace. That struct, along with some useful #define's is exported to
userspace programs in include/linux/fb.h.
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]>
---
diff -Nru a/drivers/video/fbsplash.h b/drivers/video/fbsplash.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/video/fbsplash.h 2005-03-07 16:50:34 +01:00
@@ -0,0 +1,75 @@
+/*
+ * linux/drivers/video/fbsplash.h -- Framebuffer splash headers
+ *
+ * Copyright (C) 2004-2005 Michael Januszewski <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef __FB_SPLASH_H
+#define __FB_SPLASH_H
+
+#ifndef _LINUX_FB_H
+#include
+#endif
+
+/* This is needed for vc_cons in fbcmap.c */
+#include
+
+struct fb_cursor;
+struct fb_info;
+struct vc_data;
+
+#ifdef CONFIG_FB_SPLASH
+/* fbsplash.c */
+int fbsplash_init(void);
+int fbsplash_call_helper(char* cmd, unsigned short cons);
+int fbsplash_disable(struct vc_data *vc, unsigned char redraw);
+
+/* cfbsplash.c */
+void fbsplash_putcs(struct vc_data *vc, struct fb_info *info, const unsigned
short *s, int count, int yy, int xx);
+void fbsplash_cursor(struct fb_info *info, struct fb_cursor *cursor);
+void fbsplash_clear(struct vc_data *vc, struct fb_info *info, int sy, int sx,
int height, int width);
+void fbsplash_clear_margins(struct vc_data *vc, struct fb_info *info, int
bottom_only);
+void fbsplash_blank(struct vc_data *vc, struct fb_info *info, int blank);
+void fbsplash_bmove_redraw(struct vc_data *vc, struct fb_info *info, int y,
int sx, int dx, int width);
+void fbsplash_copy(u8 *dst, u8 *src, int height, int width, int linebytes, int
srclinesbytes, int bpp);
+void fbsplash_fix_pseudo_pal(struct fb_info *info, struct vc_data *vc);
+
+/* vt.c */
+void acquire_console_sem(void);
+void release_console_sem(void);
+void do_unblank_screen(int entering_gfx);
+
+/* struct vc_data *y */
+#define fbsplash_active_vc(y) (y->vc_splash.state && y->vc_splash.theme)
+
+/* struct fb_info *x, struct vc_data *y */
+#define fbsplash_active_nores(x,y) (x->splash.data && fbsplash_active_vc(y))
+
+/* struct fb_info *x, struct vc_data *y */
+#define fbsplash_active(x,y) (fbsplash_active_nores(x,y) &&\
+ x->splash.width == x->var.xres && \
+ x->splash.height == x->var.yres &&\
+ x->splash.depth == x->var.bits_per_pixel)
+
+
+#else /* CONFIG_FB_SPLASH */
+
+static inline void fbsplash_putcs(struct vc_data *vc, struct fb_info *info,
const unsigned short *s, int count, int yy, int xx) {}
+static inline void fbsplash_putc(struct vc_data *vc, struct fb_info *info, int
c, int ypos, int xpos) {}
+static inline void fbsplash_cursor(struct fb_info *info, struct fb_cursor
*cursor) {}
+static inline void fbsplash_clear(struct vc_data *vc, struct fb_info *info,
int sy, int sx, int height, int width) {}
+static inline void fbsplash_clear_margins(struct vc_data *vc, struct fb_info
*info, int bottom_only) {}
+static inline void fbsplash_blank(struct vc_data *vc, struct fb_info *info,
int blank) {}
+static inline void fbsplash_bmove_redraw(struct vc_data *vc, struct fb_info
*info, int y, int sx, int dx, int width) {}
+static inline int fbsplash_call_helper(char* cmd, unsigned short cons) {
return 0; }
+static inline int fbsplash_init(void) { return 0; }
+static inline int fbsplash_disable(struct vc_data *vc, unsigned char redraw) {
return 0; }
+
+#define fbsplash_active_vc(y) (0)
+#define fbsplash_active_nores(x,y) (0)
+#define fbsplash_active(x,y) (0)
+
+#endif /* CONFIG_FB_SPLASH */
+
+#endif /* __FB_SPLASH_H */
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h2005-03-07 16:50:34 +01:00
+++ b/include/linux/fb.h2005-03-07 16:50:34 +01:00
@@ -8,6 +8,13 @@
#define FB_MAJOR 29
#define FB_MAX 32 /* sufficient for now */
+struct fb_splash_iowrapper
+{
+ unsigned short vc; /* Virtual console */
+ unsigned char origin; /* Point of origin of the request */
+ void *data;
+};
+
/* ioctls
0x46 is 'F' */
#define FBIOGET_VSCREENINFO0x4600
@@ -35,7 +42,15 @@
#define FBIOGET_HWCINFO 0x4616
#define FBIOPUT_MODEINFO0x4617
#define FBIOGET_DISPINFO0x4618
-
+#define FBIOSPLASH_SETCFG _IOWR('F', 0x19, struct fb_splash_iowrapper)
+#define FBIOSPLASH_GETCFG _IOR('F', 0x1A, struct fb_splash_iowrapper)
+#define FBIOSPLASH_SETSTATE_IOWR('F', 0x1B, struct fb_splash_iowrapper)
+#define FBIOSPLASH_GETSTATE_IOR('F', 0x1C, struct fb_splash_iowrapper)
+#define FBIOSPLASH_SETPIC _IOWR('F', 0x1D, struct fb_splash_iowrapper)
+
+#define FB_SPLASH_THEME_LEN128 /* Maximum lenght of a theme
name */
+#define FB_SPLASH_IO_ORIG_KERNEL 0 /* Kernel ioctl origin */
+#define FB_SPLASH_IO_ORIG_USER 1 /* User ioctl
[announce 1/7] fbsplash - the core interface
The core splash interface handles interaction with the userspace helper.
All communication is done via ioctls on the fbsplash device, which is a
misc character device.
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]>
---
diff -Nru a/drivers/video/fbsplash.c b/drivers/video/fbsplash.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/video/fbsplash.c 2005-03-07 16:50:34 +01:00
@@ -0,0 +1,406 @@
+/*
+ * linux/drivers/video/fbsplash.c -- Framebuffer splash core interface
+ *
+ * Copyright (C) 2004-2005 Michael Januszewski <[EMAIL PROTECTED]>
+ *
+ * Code based upon "Bootsplash" (C) 2001-2003
+ * Volker Poplawski <[EMAIL PROTECTED]>,
+ * Stefan Reinauer <[EMAIL PROTECTED]>,
+ * Steffen Winterfeldt <[EMAIL PROTECTED]>,
+ * Michael Schroeder <[EMAIL PROTECTED]>,
+ * Ken Wimer <[EMAIL PROTECTED]>.
+ *
+ * Splash render routines are located in /linux/drivers/video/cfbsplash.c
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "console/fbcon.h"
+#include "fbsplash.h"
+
+#define SPLASH_VERSION "0.9.2"
+
+extern signed char con2fb_map[];
+static int fbsplash_enable(struct vc_data *vc);
+char fbsplash_path[KMOD_PATH_LEN] = "/sbin/splash_helper";
+
+int fbsplash_call_helper(char* cmd, unsigned short vc)
+{
+ char *envp[] = {
+ "HOME=/",
+ "PATH=/sbin:/bin",
+ NULL
+ };
+
+ char tfb[5];
+ char tcons[5];
+ unsigned char fb = (int) con2fb_map[vc];
+
+ char *argv[] = {
+ fbsplash_path,
+ "2",
+ cmd,
+ tcons,
+ tfb,
+ vc_cons[vc].d->vc_splash.theme,
+ NULL
+ };
+
+ snprintf(tfb,5,"%d",fb);
+ snprintf(tcons,5,"%d",vc);
+
+ return call_usermodehelper(fbsplash_path, argv, envp, 1);
+}
+
+/* Disables fbsplash on a virtual console; called with console sem held. */
+int fbsplash_disable(struct vc_data *vc, unsigned char redraw)
+{
+ struct fb_info* info;
+
+ if (!vc->vc_splash.state)
+ return -EINVAL;
+
+ info = registered_fb[(int) con2fb_map[vc->vc_num]];
+
+ if (info == NULL)
+ return -EINVAL;
+
+ vc->vc_splash.state = 0;
+ vc_resize(vc->vc_num, info->var.xres / vc->vc_font.width,
+ info->var.yres / vc->vc_font.height);
+
+ if (fg_console == vc->vc_num && redraw) {
+ redraw_screen(fg_console, 0);
+ update_region(fg_console, vc->vc_origin +
+ vc->vc_size_row * vc->vc_top,
+ vc->vc_size_row * (vc->vc_bottom - vc->vc_top) /
2);
+ }
+
+ printk(KERN_INFO "fbsplash: switched splash state to 'off' on console
%d\n",
+vc->vc_num);
+
+ return 0;
+}
+
+/* Enables fbsplash on a virtual console; called with console sem held. */
+static int fbsplash_enable(struct vc_data *vc)
+{
+ struct fb_info* info;
+
+ info = registered_fb[(int) con2fb_map[vc->vc_num]];
+
+ if (vc->vc_splash.twidth == 0 || vc->vc_splash.theight == 0 ||
+ info == NULL || vc->vc_splash.state || (!info->splash.data &&
+ vc->vc_num == fg_console))
+ return -EINVAL;
+
+ vc->vc_splash.state = 1;
+ vc_resize(vc->vc_num, vc->vc_splash.twidth / vc->vc_font.width,
+ vc->vc_splash.theight / vc->vc_font.height);
+
+ if (fg_console == vc->vc_num) {
+ redraw_screen(fg_console, 0);
+ update_region(fg_console, vc->vc_origin +
+ vc->vc_size_row * vc->vc_top,
+ vc->vc_size_row * (vc->vc_bottom - vc->vc_top) /
2);
+ fbsplash_clear_margins(vc, info, 0);
+ }
+
+ printk(KERN_INFO "fbsplash: switched splash state to 'on' on console
%d\n",
+vc->vc_num);
+
+ return 0;
+}
+
+static inline int fbsplash_ioctl_dosetstate(struct vc_data *vc, unsigned int
__user* state, unsigned char origin)
+{
+ int tmp, ret;
+
+ if (get_user(tmp, state))
+ return -EFAULT;
+
+ if (origin == FB_SPLASH_IO_ORIG_USER)
+ acquire_console_sem();
+ if (!tmp)
+ ret = fbsplash_disable(vc, 1);
+ else
+ ret = fbsplash_enable(vc);
+ if (origin == FB_SPLASH_IO_ORIG_USER)
+ release_console_sem();
+
+ return ret;
+}
+
+static inline int fbsplash_ioctl_dogetstate(struct vc_data *vc, unsigned int
__user *state)
+{
+
[announce 0/7] fbsplash - The Framebuffer Splash
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. Truecolor, directcolor and pseudocolor modes are supported. Fbsplash has no dependency on a specific framebuffer driver. It has been tested with at least vesafb, rivafb and radeonfb. Technical details about the userspace<->kernelspace interface can be found in patch 07/07, which contains the documentation. The userspace utilities that make use of fbsplash can be found on: http://dev.gentoo.org/~spock/projects/splashutils/ Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl - 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/
[announce 0/7] fbsplash - The Framebuffer Splash
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. Truecolor, directcolor and pseudocolor modes are supported. Fbsplash has no dependency on a specific framebuffer driver. It has been tested with at least vesafb, rivafb and radeonfb. Technical details about the userspace-kernelspace interface can be found in patch 07/07, which contains the documentation. The userspace utilities that make use of fbsplash can be found on: http://dev.gentoo.org/~spock/projects/splashutils/ Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl - 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/
