tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wsdisplay framebuffer info



Hi,

what about using proplib(3)s insted of a binary interface?


Regards,

Stephan

2013/1/22 Michael <macallan%netbsd.org@localhost>:
> Hello,
>
> On Tue, 22 Jan 2013 21:03:00 +0100
> Martin Husemann <martin%duskware.de@localhost> wrote:
>
>> On Tue, Jan 22, 2013 at 02:26:32PM -0500, Michael wrote:
>> > Anything I missed? Comments?
>>
>> Looks good and is long overdue!
>>
>> Not sure if you want to go there in the first step, but I wonder if you
>> should add alpha formats along with the x formats, so you can use the same
>> description for overlays and similar.
>
> Hmm, maybe the pixel format should just encode the bits and offsets for
> each channel, although that would need at least 8 bit for each ( 5+
> bits offset, 3+ for number of bits ) so we'd need an uint64_t there,
> that way we'd still have a single value to switch() with but can
> actually get all the info out of it without lots of enum-esque
> #defines.
> Also, maybe I shouldn't stick the struct directly into the ioctl() but
> do what WSDISPLAYIO_GET_EDID does - pass a struct with a pointer to a
> buffer, size of the buffer, and the number of bytes actually filled,
> that way we could just add more fields without having to break binary
> compatibility.
>
> have fun
> Michael


Home | Main Index | Thread Index | Old Index