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 support
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/vide
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 support
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]&g
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
-#in
tead 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 u
tly 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.
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/mo
resh 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 "unsub
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 depen
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
@@
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
--
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/d
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/dr
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
@@ -4
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/Documen
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/d
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
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
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
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
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
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'
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/Documentat
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
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..1
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 3
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
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
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/v
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
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
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
d-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
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/Documentat
/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-k
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 inser
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
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
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 Janusz
e 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/d
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-0
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 fini
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 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 cl
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
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 20
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 bu
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/
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
#
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/v
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/fbspla
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
--- /
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 whic
On Sun, Feb 27, 2005 at 08:41:23PM +0100, Pavel Machek wrote:
Hi,
> [aj added to the list].
>
> Andreas, who is the person to talk about this? I like redhat's
> solution the best. Pass "quiet", perhaps replace penguin with some big
> picture including penguin and chameleon or something, and do t
On Mon, Feb 28, 2005 at 06:40:15PM +0100, Pavel Machek wrote:
Hi,
> > It doesn't really need vesafb for anything. Back in the days of 2.6.7
> > I used to release a version of bootsplash that had the dep. on vesafb
> > removed. It worked fine with at least some other fb drivers.
> >
> > You mi
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.)
Sure, I'll post a patch as soon
On Sun, Feb 27, 2005 at 08:31:39PM +0100, Arjan van de Ven wrote:
> well.. how much does it really need in kernel space? I mean, with all
> drivers as modules, and the "quiet" option, initramfs runs *really*
> fast. And that can just bang a bitmap to the framebuffer as first
> thing... (rhgb does
On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote:
Hi,
> Yes, I agree, almost anything is more sane than code I posted :-(. My
> only requirement is that it works with radeonfb and similar low-level
> drivers (so that I can get suspend-to-ram to work) and that it gets
> past our brand
On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote:
> Pavel, I agree with Michal, take a look at this version of the code
> instead of the version that you posted. It's a _whole_ lot more sane,
> and possibly even mergable.
>
> Michal, any thoughts on submitting it for inclusion? It seems
On Fri, Feb 18, 2005 at 05:52:54PM +0100, Pavel Machek wrote:
Hi,
> Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> taken from suse kernel. I'll probably try to modify it to work with
> radeonfb.
>
> Any ideas why bootsplash needs to hack into vesafb? It only uses
> vesa
61 matches
Mail list logo
