linux-kernel - Re: Proposal for a low-level Linux display framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201109211526.33687.heiko@sntech.de>
Date:	Wed, 21 Sep 2011 15:26:33 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linaro-dev@...ts.linaro.org,
	"Clark, Rob" <rob@...com>, Archit Taneja <archit@...com>,
	Nishant Kamat <nskamat@...com>
Subject: Re: Proposal for a low-level Linux display framework

Hi,

Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
> Now, I'm quite sure the above framework could work quite well with any
> OMAP like hardware, with unified memory (i.e. the video buffers are in
> SDRAM) and 3D chips and similar components are separate. But what I'm
> not sure is how desktop world's gfx cards change things. Most probably
> all the above components can be found from there also in some form, but
> are there some interdependencies between 3D/buffer management/something
> else and the video output side?
If I have read your proposal right, it could also help in better supporting 
epaper-displays. 

The current drivers each (re-)implement the deferredIo logic needed to drive 
such systems (catching and combining updates to the framebuffer) and combine 
this with the actual display driver which issues specific commands to the 
display hardware. Also a board-specific driver is needed to implement the 
actual transport to the display which seems be done via this i80 command 
protocol over GPIOs or the LCD controllers of SoCs.

If one were to split this it could be realised like

----------------   ---------------   -------------
| deferredIOFb | - | DisplayCtrl | - | Transport |
----------------   ---------------   -------------

An interesting tidbit is that on the ereaders I'm working on the LCD 
controller should be able to do some sort of pseudo DMA operation.
The normal way to transmit data to epaper displays is:
- issue update command with dimension of the regions to update
- read relevant pixeldata from fb and write it to the i80 in a loop
- issue stop-update command

On the S3C2416 it could go like:
- issue update command
- describe to the lcd controller the source memory region
- let the lcd controller transmit exactly one frame
- issue stop update command
So the transport would need to get the memory addresses of the region to 
update from the framebuffer driver.

Also this system could possibly use some of the drawing routines from the 
S3C2416 SoC.

Essentially needed would be a s3c-fb with deferredio-addon and the lcd 
controller separated from it. I'm still not sure how this all could fit 
together but I would guess separating framebuffer and display control would 
help.


Heiko 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/