On Thu, Feb 28, 2013 at 1:20 PM, David Herrmann wrote:
> We currently have different drivers that can make use of "system
> framebuffers" (as I call them for now):
> - vgacon
> - fbdev
> - DRM
> (- vgalog) (similar to fblog/drmlog but using vga/VBE)
offb
Gr{oetje,eeting}s,
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough in
>> I'm unsure if I like this or not, and I don't see why its greatly more
>> useful than the interface we have now.
>
> This interface at least solves the problem with having vesafb,
> uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar
> drivers from accessing the system framebuffer
Hi Dave
On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote:
>>
>> This series tries to fix the mess with global system framebuffer access in
>> device drivers. Currently, architecture initialization sets the "screen_info"
>> object according to the system framebuffer that was detected during boo
>
> This series tries to fix the mess with global system framebuffer access in
> device drivers. Currently, architecture initialization sets the "screen_info"
> object according to the system framebuffer that was detected during boot. The
> device driver that can map VMEM first gets access to it. T
Hi
This series tries to fix the mess with global system framebuffer access in
device drivers. Currently, architecture initialization sets the "screen_info"
object according to the system framebuffer that was detected during boot. The
device driver that can map VMEM first gets access to it. There i
6 matches
Mail list logo
