[lkml]   [2011]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Proposal for a low-level Linux display framework
    On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen <> wrote:

    > 2) panel drivers, handles panel specific things. Each panel may support
    > custom commands and features, for which we need a dedicated driver. And
    > this driver is not platform specific, but should work with any platform
    > which has the output used with the panel.

    Right, we've got DDC ports (which are just i2c) and DisplayPort aux
    channel stuff.

    The DDC stuff is abstracted out and shared across the drivers, but the
    DisplayPort aux channel code is not -- it's duplicated in every output

    > DSI bus is a half-duplex serial bus, and while it's designed for
    > displays you could use it easily for any communication between the SoC
    > and the peripheral.

    Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.

    > The point is that we cannot have standard "MIPI DSI command mode panel
    > driver" which would work for all DSI cmd mode panels, but we need (in
    > the worst case) separate driver for each panel.

    It sounds like we do want to share code for those bits, much like we
    have DDC split out now. And, we should do something about the
    DisplayPort aux channel stuff to avoid duplicating it everywhere.

    I'm not sure a common interface to all of these different
    channels makes sense, but surely a DSI library and an aux channel
    library would fit nicely alongside the existing DDC library.

    I suspect helper functions would be a good model to follow, rather than
    trying to create a whole new device infrastructure; some of the
    communication paths aren't easily separable from the underlying output

    Oh, I think you're also trying to get at how we expose some of these
    controls outside of the display driver -- right now, they're mostly
    exposed as properties on the output device. Things like backlight
    brightness, a million analog TV output values, dithering control and
    other more esoteric controls.

    DRM properties include booleans, enumerations, integer ranges and chunks
    of binary data. Some are read-only (like EDID data), some are writable
    (like overscan values).

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2011-09-16 05:35    [W:0.020 / U:5.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site