On 12/31/2017 01:53 PM, Alan Cox wrote:
> On Tue, 19 Dec 2017 15:07:53 +0100
> Oliver Neukum wrote:
>
>> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
Would you like me to extend the FB API or not?
>>>
>>> Yes. Well for real I'd like you to do kms, so maybe you need to ex
On Tue, 19 Dec 2017 15:07:53 +0100
Oliver Neukum wrote:
> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
> > > Would you like me to extend the FB API or not?
> >
> > Yes. Well for real I'd like you to do kms, so maybe you need to explain
> > why exactly you absolutely have to
On 12/20/2017 04:35 PM, Ray Strode wrote:
> Hi,
>
>> Actually, I don't want that :)
>>
>> This was a design decision that I've made to keep the code small and simple
>> to audit.
>> As it is, the simple bootsplash code will make 99% of people happy.
> You think only 1% of linux users have more th
Hi,
> Actually, I don't want that :)
>
> This was a design decision that I've made to keep the code small and simple
> to audit.
> As it is, the simple bootsplash code will make 99% of people happy.
You think only 1% of linux users have more than one monitor or a 4k screen?
> I've made this deci
On 12/19/2017 10:01 PM, Ray Strode wrote:
> Hi,
>
> On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote:
>> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
>> functional extension of that. It just happens that fbcon sits on top of FB,
>> so I
>> work with what I get.
On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
> On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote:
> >> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> >>> The problem is that defio is totally not how a real driver works.
> >>
> >> But
Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
> > Would you like me to extend the FB API or not?
>
> Yes. Well for real I'd like you to do kms, so maybe you need to explain
> why exactly you absolutely have to use fbdev (aka which driver isn't
> supported by drm that you want to
Hi,
On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote:
> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
> functional extension of that. It just happens that fbcon sits on top of FB,
> so I
> work with what I get.
>
> And the console in turn happens to work on all
On 12/19/2017 05:09 PM, Daniel Vetter wrote:
> btw the reason drmcon didn't move is that David Herrmann moved on from
> hacking on graphics stuff, and no one needs it. There's nothing
> fundamentally wrong with his patches for a basic emergency console on
> plain drm, or the simpledrm driver to get
On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote:
>> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
>>> The problem is that defio is totally not how a real driver works.
>>
>> But they do exist and I can't ignore them.
>>
>> I'm afraid I don't understa
btw the reason drmcon didn't move is that David Herrmann moved on from
hacking on graphics stuff, and no one needs it. There's nothing
fundamentally wrong with his patches for a basic emergency console on
plain drm, or the simpledrm driver to get a basic drm framebuffer up
on vesafb/efifb and frien
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote:
> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
>> Where do drivers deal with struct file deep down?
>
> As an example, I remembered this to be the case in nouveau's code for
> allocating a framebuffer. So I checked, and it's much better now.
>
>
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> Where do drivers deal with struct file deep down?
As an example, I remembered this to be the case in nouveau's code for
allocating a framebuffer. So I checked, and it's much better now.
So I was mistaken about this - sorry.
Thanks a lot for cleanin
On Tue, Dec 19, 2017 at 02:34:22PM +0100, Max Staudt wrote:
> On 12/19/2017 01:23 PM, Daniel Vetter wrote:
> > On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
> >> 2) We need to go out of the way when a graphical application starts, and
> >> come back when it's done. fbcon already has t
On 12/19/2017 01:23 PM, Daniel Vetter wrote:
> On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
>> 2) We need to go out of the way when a graphical application starts, and
>> come back when it's done. fbcon already has the logic for this, and
>> fbcon is also the thing we're trying to hi
On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
> On 12/13/2017 10:35 PM, Daniel Vetter wrote:
> > Using drm directly would allow you to flush the contents without the fake
> > (and tbh, really expensive on most drivers) copy op. If you insist on
> > using fbdev for this stuff, then at
On 12/13/2017 10:35 PM, Daniel Vetter wrote:
> Using drm directly would allow you to flush the contents without the fake
> (and tbh, really expensive on most drivers) copy op. If you insist on
> using fbdev for this stuff, then at least add a new hook to flush cpu
> rendering.
My reasoning is as f
On Wed, Dec 13, 2017 at 08:47:45PM +0100, Max Staudt wrote:
> Framebuffers with deferred I/O need to be flushed to the screen
> explicitly, since we use neither the mmap nor the file I/O abstractions
> that handle this for userspace FB clients.
>
> Example: xenfb
>
> Some framebuffer drivers impl
Framebuffers with deferred I/O need to be flushed to the screen
explicitly, since we use neither the mmap nor the file I/O abstractions
that handle this for userspace FB clients.
Example: xenfb
Some framebuffer drivers implement lazy access to the screen without
actually exposing a fbdefio interf
19 matches
Mail list logo
