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?
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
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 a
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?
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?
Anyway,
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
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
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
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
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.
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 which use
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.
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
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 LocalBus are
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
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 it
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
[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
> >
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
>
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
[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 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 handle it by
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:
> > >
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
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
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:
Actually...
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]>
> > ---
> >
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
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/Kconfig|
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 shouldn't be
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 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 one
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
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
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 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 logo.c and code
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 declarations of logos
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
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
On 10/8/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
BTW, what path do framebuffer patches take to get into Linus' tree?
Does he pull your tree directly, or do they go through someone else's
tree?
They all go to -mm tree, unless
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote:
On 10/8/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
BTW, what path do framebuffer patches take to get into Linus' tree?
Does he pull your tree directly, or do they go through
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
On 10/2/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote:
Assuming there are no major issues, I'd like to get this patch series
queued up for inclusion in 2.6.24.
Okay.
Tony
BTW, what path do framebuffer patches take to get into Linus'
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
On 10/2/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote:
Assuming there are no major issues, I'd like to get this patch series
queued up for inclusion in 2.6.24.
Okay.
Tony
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
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
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
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]
Sorry, I
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 +
>
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.c |1
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
>
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
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
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
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
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
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 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 100644
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 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 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 the
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]
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] fbdev: Add
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
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
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
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 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 so that it
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
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-seq =
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
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
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
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
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
>
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 linux/fs.h
+#include
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 @@
+#ifndef
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
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,
+
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
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,
+
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
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
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
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
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
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 Ferre
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 file
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 in the fb layer
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]>
> ---
>
1 - 100 of 267 matches
Mail list logo
