Re: Idea of a v4l -> fb interface driver

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

 



On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä <syrjala@xxxxxx> wrote:
> On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote:
>> On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
>> > If he wants different (independent) content on each output, just provide
>> > multiple /dev/fbX devices. I admit that we could use a controlling interface
>> > here that decides which user (application) might draw at a time to the
>> > interface which they currently only do if they are the active VT.
>> > If you want 2 or more outputs to be merged as one just configure this in the
>> > driver.
>> > The only thing that is impossible to do in fbdev is controlling 2 or more
>> > independent display outputs that access the same buffer. But that's not an
>> > issue I think.
>> > The things above only could use a unification of how to set them up on
>> > module load time (as only limited runtime changes are permited given that we
>> > must always be able to support a mode that we once entered during runtime).
>> >
>>
>> What about changing outputs on the fly (turn off VGA, turn on DVI,
>> switch between multi-head and single-head, etc) or encoders shared
>> between multiple connectors (think a single dac shared between a VGA
>> and a TV port); how do you expose them easily as separate fbdevs?
>> Lots of stuff is doable with fbdev, but it's nicer with kms.
>
> But actually getting your data onto the screen is a lot easier with
> fbdev. There's no standard API in drm to actually allocate the
> framebuffer and manipulate it. You always need a user space driver
> to go along with the kernel bits.
>
> I'm not saying fbdev is better than drm/kms but at least it can be
> used to write simple applications that work across different
> hardware. Perhaps that's something that should be addressed in the
> drm API.
>

http://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg48461.html

I started writing a "dumb" API for KMS, it got stuck on whether to
expose cursors or not, I must dig out the branch.

It basically was a create + map API. I'll see if I can get it finished off.

The main reason we avoided a fully generic interface is there isn't
really a generic way to abstract acceleration on a modern GPU, and
buffer allocation on most modern GPUs doesn't want a linear simple
buffer. We felt doing a compromised generic interface would lead
people down the wrong path into believing they could easily move from
the "dumb" interface to a real accelerated one.

There is a userspace library called libkms that abstracts this stuff,
but I'd like to just have the kernel do it.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux