Anton Vorontsov writes:
> > I was wondering if it would be sufficient to provide alternative
> > versions of fb_readl, fb_writel etc. that do byte-swapping.
>
> This is of course viable alternative. And I was considering this, but
> later I abandoned the idea: that way we'll end up doing math in
On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
> On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > Bizarrely, the original author of the patch (Anton) has fallen off the
> > > cc.
> > > Could whoever did that please thwap himself?
> >
Paul Mackerras schrieb:
Andrew Morton writes:
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
I
On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> > Could whoever did that please thwap himself?
> >
> > Anyway, my head is now officially spinning. Did anyone actually have
Andrew Morton writes:
> Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> Could whoever did that please thwap himself?
>
> Anyway, my head is now officially spinning. Did anyone actually have a
> reason why we shouldn't proceed with Anton's patch?
I was wondering if
On Tue, 2008-02-19 at 19:47 -0500, [EMAIL PROTECTED] wrote:
> On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> > On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]
> > wrote:
> > > That's not an issue in my case. The SM50x can be connected to
> > > either an PCI or some Lo
On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]
> wrote:
> > That's not an issue in my case. The SM50x can be connected to
> > either an PCI or some Local/CPU-whateverbus IF.
> > I.e. on the MPC85xx PowerPC, PCI and LocalB
Andrew Morton schrieb:
On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote:
Benjamin Herrenschmidt schrieb:
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
[EMAIL PROTECTED] schrieb:
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
I know two fb drive
On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt schrieb:
> > On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
> >> [EMAIL PROTECTED] schrieb:
> >>> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> I know two fb drivers wh
Benjamin Herrenschmidt schrieb:
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
[EMAIL PROTECTED] schrieb:
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actu
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
> [EMAIL PROTECTED] schrieb:
> > On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> >> I know two fb drivers which use endianess information (pm2fb and
> >> s3c2410fb).
> >> Both resolve endianess at driver level. Actually, both han
[EMAIL PROTECTED] schrieb:
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting
special
bits so the graphics chip itself reorder bytes to
On Mon, Feb 18, 2008 at 12:30:11PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> > I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> > Both resolve endianess at driver level. Actually, both handle it by setting
> > special
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> Both resolve endianess at driver level. Actually, both handle it by setting
> special
> bits so the graphics chip itself reorder bytes to transform foreign
> e
On Sun, 17 Feb 2008 10:44:32 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008, Anton Vorontsov wrote:
> > On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> > > On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <[EMAIL PROTECTED]>
> > > wrote:
> > > A
On Fri, 15 Feb 2008, Anton Vorontsov wrote:
> On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> > On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > > This patch adds support for the framebuffers with non-native
> > > endianness. This is done via FBINFO_
On Wed, 2008-01-30 at 08:38 -0800, Randy Dunlap wrote:
> On Wed, 30 Jan 2008 17:53:20 +0800 Bryan Wu wrote:
>
> > From: Michael Hennerich <[EMAIL PROTECTED]>
> >
> > Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> > ---
> > drivers/video/Kc
On Wed, 30 Jan 2008 17:53:20 +0800 Bryan Wu wrote:
> From: Michael Hennerich <[EMAIL PROTECTED]>
>
> Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> ---
> drivers/video/Kconfig| 53 ++--
All of these non-bfin changes to Kconfig s
On Sun, 27 Jan 2008 12:31:16 +0100
Michal Januszewski <[EMAIL PROTECTED]> wrote:
> 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 on
Tiny patch that removes not needed "inline" and renames
function : exit_contrast() -> exit_backlight().
It adds the missing exit_backlight() in probe()
error path.
Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]>
---
Follows comments from Andrew Morton and Haavard Skinnemoen.
Thanks to both of
On Fri, Dec 14, 2007 at 09:49:03PM +0100, Geert Uytterhoeven wrote:
> On Thu, 13 Dec 2007, Marcin Slusarz wrote:
> > On Thu, Dec 13, 2007 at 02:31:11AM -0800, Andrew Morton wrote:
> > > On Sun, 9 Dec 2007 22:40:31 +0100 Marcin Ślusarz <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > logo: move decla
On Thu, 13 Dec 2007, Marcin Slusarz wrote:
> On Thu, Dec 13, 2007 at 02:31:11AM -0800, Andrew Morton wrote:
> > On Sun, 9 Dec 2007 22:40:31 +0100 Marcin Ślusarz <[EMAIL PROTECTED]> wrote:
> >
> > > logo: move declarations of logos to linux_logo.h
> > >
> > > there was a mismatch between externs in
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote:
> On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > > BTW, what path do framebuffer patches take to get into Linus' tree?
> > > Does he pull your tree directly, or do they g
On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > BTW, what path do framebuffer patches take to get into Linus' tree?
> > Does he pull your tree directly, or do they go through someone else's
> > tree?
>
> They all go to -mm tree,
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> On 10/2/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote:
> > > Assuming there are no major issues, I'd like to get this patch series
> > > queued up for inclusion in 2.6.24.
> >
> >
On 10/2/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote:
> > Assuming there are no major issues, I'd like to get this patch series
> > queued up for inclusion in 2.6.24.
>
> Okay.
>
> Tony
BTW, what path do framebuffer patches take to get i
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote:
> (resend due to mailer issues. Apologies to anyone receiving this twice)
>
> This patch series reworks the Xilinx framebuffer driver and then adds
> an of_platform bus binding. The of_platform bus binding is needed to use
> the driver in ar
On Tue, Sep 04, 2007 at 03:45:12PM +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2007-09-04 at 12:58 +0200, [EMAIL PROTECTED] wrote:
> > .. which can be found in Acer Aspire 5100.
> >
> > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
>
> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
On Tue, 2007-09-04 at 12:58 +0200, [EMAIL PROTECTED] wrote:
> .. which can be found in Acer Aspire 5100.
>
> Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> drivers/video/aty/ati_ids.h |1 +
> drivers/video/aty/radeon_base
On Sun, 2007-08-26 at 21:09 +0200, Michal Januszewski wrote:
> On Wed, Jul 18, 2007 at 11:18:15PM +0800, Antonino A. Daplas wrote:
>
> 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,hfm
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
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
On Sat, 25 Aug 2007 10:59:31 +0200 Michal Januszewski wrote:
> 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
On Thu, 9 Aug 2007, Huang, Ying wrote:
> Changelog between this version and previous version (v3 of x86_64 EFI
> support patch).
>
> 1. The include files of efifb.c is cleaned up.
> 2. Make CONFIG_FB_EFI do not depend on CONFIG_EFI.
BTW, the recommended place to put changelogs (so the tools will
On Wed, 2007-07-18 at 16:38 +0200, Ondrej Zajicek wrote:
> On Wed, Jul 18, 2007 at 10:41:02AM +0200, Michal Januszewski 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
On Fri, 2007-07-13 at 11:09 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Andrew Morton wrote:
> > On Fri, 13 Jul 2007 10:52:10 +0200 (CEST) Geert Uytterhoeven <[EMAIL
> > PROTECTED]> wrote:
> >
> > > > > Summaries:
> > > > > [1] fbdev: extract fb_show_logo_line()
> > > > > [2] fbde
On Sat, 2007-06-23 at 11:04 -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[EMAIL PROTECTED]>
> wrote:
>
> > If the refresh rate hasn't been explicitly specified, fd_find_mode
> > currently returns the first mode with the requested resolution. Change
> > it s
On Sat, 2007-06-23 at 12:50 +0200, Michal Januszewski wrote:
> 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.
>
On Sat, 2007-06-23 at 12:49 +0200, Michal Januszewski wrote:
My apologies for the delayed response. I had problems with my ISP.
> 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 h
On Sat, Jun 23, 2007 at 12:52:43PM +0200, Michal Januszewski wrote:
>+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->s
On Sun, 27 May 2007, Antonino A. Daplas wrote:
> Add function helper, fb_is_display_device(). Given struct fb_info, it will
^^^
primary
> return a nonzero value if the device is the primary display.
> +static inline int fb_is_primary_
Hi Nicolas,
> + info->fix.line_length = info->var.xres_virtual *
> (info->var.bits_per_pixel / 8);
line_length will always be 0 for bits_per_pixel < 8.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
On Thu, 2007-05-17 at 11:43 +0200, Geert Uytterhoeven wrote:
> On Thu, 16 May 2007, Antonino A. Daplas wrote:
> > diff --git a/include/asm-m68k/fb.h b/include/asm-m68k/fb.h
> > new file mode 100644
> > index 000..7d4a28f
> > --- /dev/null
> > +++ b/include/asm-m68k/fb.h
> > @@ -0,0 +1,28 @@
> >
On Thu, 16 May 2007, Antonino A. Daplas wrote:
> diff --git a/include/asm-m68k/fb.h b/include/asm-m68k/fb.h
> new file mode 100644
> index 000..7d4a28f
> --- /dev/null
> +++ b/include/asm-m68k/fb.h
> @@ -0,0 +1,28 @@
> +#ifndef _ASM_FB_H_
> +#define _ASM_FB_H_
> +
> +#include
> +#include
> +#
From: Nicolas Ferre <[EMAIL PROTECTED]>
Adds a framebuffer driver to ATMEL AT91SAM9x and AT32 aka AVR32 platforms.
Those chips share quite the same
IP and this code is suitable for both architectures.
Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]>
---
This second patch is rebuild following A
Antonino A. Daplas :
On Mon, 2007-05-07 at 16:11 +0200, Nicolas Ferre wrote:
From: Nicolas Ferre <[EMAIL PROTECTED]>
+
+static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .xpans
Hi Antonio,
Thanks for the feedback. I'm just going to reply to one of your
comments and leave the rest for Nicolas...
On Tue, 08 May 2007 05:40:17 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
> > +static int __init atmel_lcdfb_init(void)
> > +{
> > + return platform_driver_probe(&atm
From: "Antonino A. Daplas" <[EMAIL PROTECTED]>
Date: Tue, 08 May 2007 06:55:52 +0800
> On Mon, 2007-05-07 at 13:47 -0700, David Miller wrote:
> > From: Haavard Skinnemoen <[EMAIL PROTECTED]>
> > Date: Mon, 7 May 2007 17:20:33 +0200
> >
>
> > We're at the point where these two snippets of code i
On Mon, 2007-05-07 at 13:47 -0700, David Miller wrote:
> From: Haavard Skinnemoen <[EMAIL PROTECTED]>
> Date: Mon, 7 May 2007 17:20:33 +0200
>
> We're at the point where these two snippets of code in the fb layer
> are a total mess of ifdefs.
>
> It's time we made an include/asm-foo/fb.h header
On Mon, 2007-05-07 at 16:11 +0200, Nicolas Ferre wrote:
> From: Nicolas Ferre <[EMAIL PROTECTED]>
>
> Adds a framebuffer driver to ATMEL AT91SAM9x and AT32
> aka AVR32 platforms. Those chips share quite the same
> IP and this code is suitable for both architectures.
>
> Signed-off-by: Nicolas Fe
On Wed, 31 Jan 2007, Geert Uytterhoeven wrote:
> Move the external declarations for the various linux logo structures to
> . As a consequence, I had to remove the `const', as
> `const'
> is incompatible with `__initdata'.
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> ---
> arch/pow
On Mon, 2007-03-05 at 19:39 +0900, Paul Mundt wrote:
> There are cases when we do not want to wait on the delay for
> automatically updating the "real" framebuffer, this implements a
> simple ->fsync() hook for explicitly flushing the deferred I/O
> work. The ->page_mkwrite() handler will rearm the
On 3/1/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
On Sun, Feb 25, 2007 at 06:13:12AM +0100, Jaya Kumar wrote:
> This patch implements deferred IO support in fbdev. Deferred IO is a way to
> delay and repurpose IO. This implementation is done using mm's page_mkwrite
> and page_mkclean hooks in orde
On Thu, Mar 01, 2007 at 02:25:55PM +0100, Geert Uytterhoeven wrote:
> On Thu, 1 Mar 2007, Paul Mundt wrote:
> > @@ -1074,9 +1074,9 @@ static ssize_t sm501fb_crtsrc_store(struct device
> > *dev,
> > if (len < 1)
> > return -EINVAL;
> >
> > - if (strnicmp(buf, "crt", sizeof("crt"
On Thu, 1 Mar 2007, Paul Mundt wrote:
> Currently sm501fb_crtsrc_store() won't allow the routing to be changed
> via echos from userspace in to the sysfs file. The reason for this is
> that the strnicmp() for both heads uses a sizeof() for the string length,
> which ends up being strlen() + 1 (\0 i
> On Thu, Feb 22, 2007 at 12:33:35PM +0200, Paul Sokolovsky wrote:
> >
> > We in handhelds.org codebase have attached patch* to make corgi_bl
> > more suitable for general use. This patch was submitted to Richard
> > (so, more votes needed ;-) ). Otherwise, snippet I pasted is from real
> > mac
> I'm not sure I understand. What the current implementation does is to
> use host based framebuffer memory. Apps mmap that memory and draw to
> that. Then after the delay, that framebuffer is written to the
> device's memory. That's the scenario for hecubafb where the Apollo
> controller maintain
On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
> On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> > >
> > > Applied. No noticeable difference, in the sense that the EDID debug
> > > output is still the same and so
On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
>
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvid
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > > by not compiling in EDID supp
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through 1600)
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
>
> The snowy is constant and abundant, and it seems to be independent of
> video size (640 through 1600) and screen occupation (single prompt
> line to fullscreen mc session) and
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > > and they /all/ come up snowy. This
On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> and they /all/ come up snowy. This is starting to look queerer and
> queerer. I've also tried changing vf
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> > >
> > > However, I'm still getting the same snowy effects, which doesn't come
> > > as a surprise since the actua
On Thu, 2007-02-22 at 21:39 +0100, Luca Tettamanti wrote:
> Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto:
> > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
>
> Still scratching my head :|
>
> To
Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> >>
> >> As mentioned in another post in this thread, I can't get any info out
> >> of the i2c busses, b
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
>
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
>
BTW, you can also use CVT modes
On Thu, 22 Feb 2007, Antonino A. Daplas wrote:
> On Thu, 2007-02-22 at 01:35 +, James Simmons wrote:
> > > On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
>
> > > If this is an attempt to consolidate, I don't see the 'brightness'
> > > hook of backlight and lcd.
> > >
> > > If this i
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> >
> > Ah, my fault. Apply this patch on top.
>
> We're getting closer! The patch now works, and the dmesg has the following
> info:
Okay.
>
>
> ACPI: PCI Interrupt :01
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID: 10de0112
On Thu, 2007-02-22 at 09:01 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> > >
> > > As mentioned in another post in this thread, I can't get any info out
> > > of the i2c busses, because ev
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
>
> As mentioned in another post in this thread, I can't get any info out
> of the i2c busses, because even when I have them available (i.e. after
> loading nvidiafb) I get al
On Thu, 2007-02-22 at 01:35 +, James Simmons wrote:
> > On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> > If this is an attempt to consolidate, I don't see the 'brightness'
> > hook of backlight and lcd.
> >
> > If this is not a consolidation, why don't we just extend the lcd class?
> On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> > This is the new display intreface. Its goal is to provide a standard
> > interface to various types of displays. Currently we have auxdisplay,
> > output acpi device and the now defunct lcd class in the backlight directory.
> > Please
On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> This is the new display intreface. Its goal is to provide a standard
> interface to various types of displays. Currently we have auxdisplay,
> output acpi device and the now defunct lcd class in the backlight directory.
> Please apply.
Is
On 2/21/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote:
>
> You are right. I will need that. I could put that into struct
> fb_deferred_io. So drivers would setup like:
>
Is it also possible to let the drivers do the 'deferred_io'
themselves
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote:
> On 2/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > Don't you need a way to specify the maximum deferral time? E.g. a field in
> > fb_info.
> >
>
> You are right. I will need that. I could put that into struct
> fb_deferred_io. So d
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote:
> On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> > Given that, this would have to be something that's dealt with at the
> > subsystem level rather than in individual drivers, hence the desire to
> > see something like this more generically
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> On 2/6/07, James Simmons <[EMAIL PROTECTED]> wrote:
> >
> > If you can find post the manufacturer and model number we can place it on
> > the backlist in fbmon. Also we should figure out what is wrong and fix it.
>
> It's the UltraSharp
Your alive!!! I thought something happened to you.
On Tue, 20 Feb 2007, Antonino A. Daplas wrote:
> On Fri, 2007-02-16 at 13:24 +0100, Adrian Bunk wrote:
> > On Thu, Feb 15, 2007 at 03:05:26PM -0800, Randy Dunlap wrote:
> > > On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote:
> > >
>
On Fri, 2007-02-16 at 13:24 +0100, Adrian Bunk wrote:
> On Thu, Feb 15, 2007 at 03:05:26PM -0800, Randy Dunlap wrote:
> > On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote:
> >
> > >
> > > I wouldn't say it orphan. I just can't spend 8 hours a day on it.
> > > Alot of patches have bee
On 2/17/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Ok, now I'm confused O_o
The patch should be correct, but I fail to see how EDID reading succeded
before.
Sorry, but I have no idea on that :P
Maybe the snow was caused by the driver hammering the I2C bus. Just
guessing...
It it was so
Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto:
> On 2/11/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >Sorry for the delay.
>
> Ditto!
>
> It also seemed that my kernel compiling sk1llz had gone AWL, I
> couldn't get the newly compiled kernel to run, until I realized
Andrew please apply.
Acked-By: James Simmons <[EMAIL PROTECTED]>
On Fri, 16 Feb 2007, Ben Dooks wrote:
> Driver for the Silicon Motion SM501 multifunction device
> framebuffer subsystem.
>
> This driver supports both the CRT and LCD panel heads,
> with some simple acceleration for the cursor p
On Fri, Feb 16, 2007 at 09:50:45AM +, Ben Dooks wrote:
> Driver for the Silicon Motion SM501 multifunction device
> framebuffer subsystem.
>
> This driver supports both the CRT and LCD panel heads,
> with some simple acceleration for the cursor plotting
> and support for screen panning. There
On Tue, Feb 13, 2007 at 09:01:25PM +, James Simmons wrote:
>
> > Framebuffer support for the Silicon Motion SM501
> > multi-function chip.
> >
> > This driver provides a pair of framebuffer interfaces
> > for the CRT and LCD panel interfaces, and some basic
> > acceleration for the cursor.
>
> Framebuffer support for the Silicon Motion SM501
> multi-function chip.
>
> This driver provides a pair of framebuffer interfaces
> for the CRT and LCD panel interfaces, and some basic
> acceleration for the cursor.
>
> The patch has been updated slightly from the previous
> version to includi
(some of you might get this mail in double copy , sorry)
On 2/11/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Sorry for the delay.
Ditto!
It also seemed that my kernel compiling sk1llz had gone AWL, I
couldn't get the newly compiled kernel to run, until I realized the
initrd.img was mislink
5BOn Thu, Feb 08, 2007 at 05:56:02PM +, James Simmons wrote:
>
>
> Do you have a new patch?
New mfd driver posted to the linux-kernel list. Will post
new sm501 driver (fixed cursor code) and option for byte-swap
on systems with big-endian cpu and little-endian pci
--
Ben ([EMAIL PROTECTED]
Sorry for the delay.
Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto:
> On 2/8/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
> >> There is no stand alone nvidia card i2c driver. Its the issue of sharing
> > There is no stand alone nvidia card i2c driver. Its the issue of sharing
> > device interfaces with the same hardware problem again!!!
>
> Nah, nvidiafb registers the I2C busses, you can drive them with whatever
> you want through the devices exported by I2C core.
> The fact the none of the
On 2/8/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
> There is no stand alone nvidia card i2c driver. Its the issue of sharing
> device interfaces with the same hardware problem again!!!
Nah, nvidiafb registers the I2C busses,
Il Mon, Feb 05, 2007 at 10:28:36PM +0100, Giuseppe Bilotta ha scritto:
> On 2/5/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> > get-edid uses the BIOS, while the other two talk directly over the I2C
> > bus.
> >
> > Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID
> > bl
Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
>
> > On 2/5/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> > > get-edid uses the BIOS, while the other two talk directly over the I2C
> > > bus.
> > >
> > > Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the
On 2/6/07, James Simmons <[EMAIL PROTECTED]> wrote:
If you can find post the manufacturer and model number we can place it on
the backlist in fbmon. Also we should figure out what is wrong and fix it.
It's the UltraSharp UXGA display that used to come with Dell Inspiron
8200, 15" with a resolu
> On 2/5/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> > get-edid uses the BIOS, while the other two talk directly over the I2C
> > bus.
> >
> > Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID
> > block, which resides at address 0x50:
> >
> > i2cdump N 0x50 (where N i
> > > Although solving the problem at the fb layer level is probably the
> > > correct/best way to do it, I am not aware of people having problems
> > > with broken EDIDs and non-nVidia cards. By contrast, workarounds for
> > > nVidia and broken EDIDs is a very common thing to do even on Windows.
1 - 100 of 134 matches
Mail list logo
