All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linaro-dev@lists.linaro.org, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Archit Taneja <archit@ti.com>, "Clark, Rob" <rob@ti.com>
Subject: Re: Proposal for a low-level Linux display framework
Date: Thu, 15 Sep 2011 19:46:36 +0000	[thread overview]
Message-ID: <4E72561C.7060603@gmx.de> (raw)
In-Reply-To: <20110915200514.74bdcd90@lxorguk.ukuu.org.uk>

On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your own fb_read/write.
>> In theory you could even have each pixel at a completely different memory
>> location although some userspace wouldn't be happy when it could no longer mmap
>> the framebuffer.
> 
> The mmap side is trivial, the problem is that the fb layer default
> implementations of blits, fills etc only work on a kernel linear frame
> buffer. And (for example) there is not enough linear stolen memory on
> some Intel video for a 1080p console on HDMI even though the hardware is
> perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
> is there enough space to vremap it.

Okay, I see your problem. It's a bit strange you don't have acceleration. I
guess you need either your own implementation of those or adding function
pointers like fb_read/write just without the __user and use those instead of
direct memory access in the cfb* implementation if screen_base is NULL. Does not
sound like a big problem to me, but pretty inefficient, so probably copying the
existing ones and adjusting it to your needs would be preferred (just like the
sys* implementations exist).


Best regards,

Florian Tobias Schandinat

WARNING: multiple messages have this Message-ID (diff)
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Keith Packard <keithp@keithp.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-dev@lists.linaro.org,
	"Clark\, Rob" <rob@ti.com>, Archit Taneja <archit@ti.com>
Subject: Re: Proposal for a low-level Linux display framework
Date: Thu, 15 Sep 2011 19:46:36 +0000	[thread overview]
Message-ID: <4E72561C.7060603@gmx.de> (raw)
In-Reply-To: <20110915200514.74bdcd90@lxorguk.ukuu.org.uk>

On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your own fb_read/write.
>> In theory you could even have each pixel at a completely different memory
>> location although some userspace wouldn't be happy when it could no longer mmap
>> the framebuffer.
> 
> The mmap side is trivial, the problem is that the fb layer default
> implementations of blits, fills etc only work on a kernel linear frame
> buffer. And (for example) there is not enough linear stolen memory on
> some Intel video for a 1080p console on HDMI even though the hardware is
> perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
> is there enough space to vremap it.

Okay, I see your problem. It's a bit strange you don't have acceleration. I
guess you need either your own implementation of those or adding function
pointers like fb_read/write just without the __user and use those instead of
direct memory access in the cfb* implementation if screen_base is NULL. Does not
sound like a big problem to me, but pretty inefficient, so probably copying the
existing ones and adjusting it to your needs would be preferred (just like the
sys* implementations exist).


Best regards,

Florian Tobias Schandinat

  reply	other threads:[~2011-09-15 19:46 UTC|newest]

Thread overview: 143+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-15 12:07 Proposal for a low-level Linux display framework Tomi Valkeinen
2011-09-15 12:07 ` Tomi Valkeinen
2011-09-15 12:07 ` Tomi Valkeinen
2011-09-15 14:59 ` Keith Packard
2011-09-15 14:59   ` Keith Packard
2011-09-15 14:59   ` Keith Packard
2011-09-15 15:29   ` Tomi Valkeinen
2011-09-15 15:29     ` Tomi Valkeinen
2011-09-15 15:29     ` Tomi Valkeinen
2011-09-15 15:50     ` Keith Packard
2011-09-15 15:50       ` Keith Packard
2011-09-15 15:50       ` Keith Packard
2011-09-15 17:05       ` Alan Cox
2011-09-15 17:05         ` Alan Cox
2011-09-15 17:05         ` Alan Cox
2011-09-17 21:36         ` Laurent Pinchart
2011-09-17 21:36           ` Laurent Pinchart
2011-09-17 21:36           ` Laurent Pinchart
2011-09-15 17:12       ` Florian Tobias Schandinat
2011-09-15 17:12         ` Florian Tobias Schandinat
2011-09-15 17:18         ` Alan Cox
2011-09-15 17:18           ` Alan Cox
2011-09-15 17:18           ` Alan Cox
2011-09-15 17:47           ` Florian Tobias Schandinat
2011-09-15 17:47             ` Florian Tobias Schandinat
2011-09-15 19:05             ` Alan Cox
2011-09-15 19:05               ` Alan Cox
2011-09-15 19:05               ` Alan Cox
2011-09-15 19:46               ` Florian Tobias Schandinat [this message]
2011-09-15 19:46                 ` Florian Tobias Schandinat
2011-09-15 21:31                 ` Alan Cox
2011-09-15 21:31                   ` Alan Cox
2011-09-15 21:31                   ` Alan Cox
2011-09-15 17:52         ` Alex Deucher
2011-09-15 17:52           ` Alex Deucher
2011-09-15 17:56           ` Geert Uytterhoeven
2011-09-15 17:56             ` Geert Uytterhoeven
2011-09-15 18:04             ` Alex Deucher
2011-09-15 18:04               ` Alex Deucher
2011-09-15 18:04               ` Alex Deucher
2011-09-15 18:07               ` Corbin Simpson
2011-09-15 18:07               ` Corbin Simpson
2011-09-15 18:39           ` Florian Tobias Schandinat
2011-09-15 18:58             ` Alan Cox
2011-09-15 18:58               ` Alan Cox
2011-09-15 18:58               ` Alan Cox
2011-09-15 19:18               ` Florian Tobias Schandinat
     [not found]                 ` <4E724F93.1050203-Mmb7MZpHnFY@public.gmane.org>
2011-09-15 19:28                   ` Alan Cox
2011-09-15 19:28                     ` Alan Cox
2011-09-15 19:28                     ` Alan Cox
2011-09-15 19:45                 ` Alex Deucher
2011-09-15 19:45                   ` Alex Deucher
2011-09-17 14:44               ` Felipe Contreras
2011-09-17 14:44                 ` Felipe Contreras
2011-09-17 15:16                 ` Rob Clark
2011-09-17 15:16                   ` Rob Clark
2011-09-17 15:16                   ` Rob Clark
2011-09-17 16:11                   ` Florian Tobias Schandinat
2011-09-17 16:11                     ` Florian Tobias Schandinat
2011-09-17 16:47                     ` Dave Airlie
2011-09-17 16:47                       ` Dave Airlie
2011-09-17 16:47                       ` Dave Airlie
2011-09-17 18:15                       ` Florian Tobias Schandinat
2011-09-17 18:23                         ` Dave Airlie
2011-09-17 18:23                           ` Dave Airlie
2011-09-17 18:23                           ` Dave Airlie
2011-09-17 19:06                           ` Florian Tobias Schandinat
2011-09-17 19:25                             ` Corbin Simpson
2011-09-17 19:25                               ` Corbin Simpson
2011-09-17 21:25                             ` Alex Deucher
2011-09-17 21:25                               ` Alex Deucher
2011-09-17 21:25                               ` Alex Deucher
2011-09-17 20:25                           ` Alan Cox
2011-09-17 20:25                             ` Alan Cox
2011-09-17 20:25                             ` Alan Cox
2011-10-31 20:24                             ` Jesse Barnes
2011-10-31 20:24                               ` Jesse Barnes
2011-09-17 16:50                     ` Rob Clark
2011-09-17 16:50                       ` Rob Clark
2011-09-16  4:53             ` Keith Packard
2011-09-16  4:53               ` Keith Packard
2011-09-16  4:53               ` Keith Packard
2011-09-17 23:12             ` Laurent Pinchart
2011-09-17 23:12               ` Laurent Pinchart
2011-09-17 23:12               ` Laurent Pinchart
2011-09-18 16:14               ` Rob Clark
2011-09-18 16:14                 ` Rob Clark
2011-09-18 16:14                 ` Rob Clark
2011-09-18 21:55                 ` Laurent Pinchart
2011-09-18 21:55                   ` Laurent Pinchart
2011-09-18 21:55                   ` Laurent Pinchart
     [not found]               ` <201109180112.15896.laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2011-09-18 22:23                 ` Alan Cox
2011-09-18 22:23                   ` Alan Cox
2011-09-18 22:23                   ` Alan Cox
2011-09-19  0:09                   ` Rob Clark
2011-09-19  0:09                     ` Rob Clark
2011-09-20 23:32                     ` Laurent Pinchart
2011-09-20 23:32                       ` Laurent Pinchart
2011-09-15 18:12         ` Keith Packard
2011-09-15 18:12           ` Keith Packard
2011-09-15 18:12           ` Keith Packard
2011-10-01 17:30           ` Enrico Weigelt
2011-09-15 17:21       ` Tomi Valkeinen
2011-09-15 17:21         ` Tomi Valkeinen
2011-09-15 18:32         ` Rob Clark
2011-09-15 18:32           ` Rob Clark
2011-09-15 18:32           ` Rob Clark
2011-09-16  0:55         ` Keith Packard
2011-09-16  0:55           ` Keith Packard
2011-09-16  0:55           ` Keith Packard
2011-09-16  6:38           ` Tomi Valkeinen
2011-09-16  6:38             ` Tomi Valkeinen
2011-09-16 14:17           ` Daniel Vetter
2011-09-16 14:17             ` Daniel Vetter
2011-09-16 16:53           ` Alan Cox
2011-09-16 16:53             ` Alan Cox
2011-09-16 16:53             ` Alan Cox
2011-09-19  6:33             ` Tomi Valkeinen
2011-09-19  6:33               ` Tomi Valkeinen
2011-09-19  6:53               ` Keith Packard
2011-09-19  6:53                 ` Keith Packard
2011-09-19  6:53                 ` Keith Packard
2011-09-19  7:29                 ` Tomi Valkeinen
2011-09-19  7:29                   ` Tomi Valkeinen
2011-09-20  8:29                   ` Patrik Jakobsson
2011-09-20  8:29                     ` Patrik Jakobsson
2011-09-20  8:29                     ` Patrik Jakobsson
2011-09-20 15:55                     ` Keith Packard
2011-09-20 15:55                       ` Keith Packard
2011-09-20 15:55                       ` Keith Packard
2011-09-20 21:20                       ` Patrik Jakobsson
2011-09-20 21:20                         ` Patrik Jakobsson
2011-09-21  6:01                         ` Tomi Valkeinen
2011-09-21  6:01                           ` Tomi Valkeinen
2011-09-21 18:07                           ` Patrik Jakobsson
2011-09-21 18:07                             ` Patrik Jakobsson
2011-09-21 18:07                             ` Patrik Jakobsson
2011-10-01 17:34         ` Enrico Weigelt
2011-09-15 15:03 ` Kyungmin Park
2011-09-15 15:03   ` Kyungmin Park
2011-09-21 13:26 ` Heiko Stübner
2011-09-21 13:26   ` Heiko Stübner
2011-10-01 16:52 ` Enrico Weigelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E72561C.7060603@gmx.de \
    --to=florianschandinat@gmx.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=archit@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.