linux-fbdev.vger.kernel.org archive mirror
 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

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

Thread overview: 56+ 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 14:59 ` Keith Packard
2011-09-15 15:29   ` Tomi Valkeinen
2011-09-15 15:50     ` Keith Packard
2011-09-15 17:05       ` Alan Cox
2011-09-17 21:36         ` Laurent Pinchart
2011-09-15 17:12       ` Florian Tobias Schandinat
2011-09-15 17:18         ` Alan Cox
2011-09-15 17:47           ` Florian Tobias Schandinat
2011-09-15 19:05             ` Alan Cox
2011-09-15 19:46               ` Florian Tobias Schandinat [this message]
2011-09-15 21:31                 ` Alan Cox
2011-09-15 17:52         ` Alex Deucher
2011-09-15 17:56           ` Geert Uytterhoeven
2011-09-15 18:04             ` Alex Deucher
2011-09-15 18:39           ` Florian Tobias Schandinat
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:45                 ` Alex Deucher
2011-09-17 14:44               ` Felipe Contreras
2011-09-17 15:16                 ` Rob Clark
2011-09-17 16:11                   ` Florian Tobias Schandinat
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 19:06                           ` Florian Tobias Schandinat
2011-09-17 19:25                             ` Corbin Simpson
2011-09-17 21:25                             ` Alex Deucher
2011-09-17 20:25                           ` Alan Cox
2011-10-31 20:24                             ` Jesse Barnes
2011-09-17 16:50                     ` Rob Clark
2011-09-16  4:53             ` Keith Packard
2011-09-17 23:12             ` Laurent Pinchart
2011-09-18 16:14               ` Rob Clark
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-19  0:09                   ` Rob Clark
2011-09-20 23:32                     ` Laurent Pinchart
2011-09-15 18:12         ` Keith Packard
2011-09-15 17:21       ` Tomi Valkeinen
2011-09-15 18:32         ` Rob Clark
2011-09-16  0:55         ` Keith Packard
2011-09-16  6:38           ` Tomi Valkeinen
2011-09-16 14:17           ` Daniel Vetter
2011-09-16 16:53           ` Alan Cox
2011-09-19  6:33             ` Tomi Valkeinen
2011-09-19  6:53               ` Keith Packard
2011-09-19  7:29                 ` Tomi Valkeinen
2011-09-20  8:29                   ` Patrik Jakobsson
2011-09-20 15:55                     ` Keith Packard
2011-09-20 21:20                       ` Patrik Jakobsson
2011-09-21  6:01                         ` Tomi Valkeinen
2011-09-21 18:07                           ` Patrik Jakobsson
2011-09-15 15:03 ` Kyungmin Park
2011-09-21 13:26 ` Heiko Stübner

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).