On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox wrote:
> > Just tell the X driver to not use acceleration, and it you won't get
> > any acceleration used, then you get complete stability. If a driver
> > writer wants to turn off all accel in the kernel driver, it can, its
>
> In fact one thing we
On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Just tell the X driver to not use acceleration, and it you won't get
any acceleration used, then you get complete stability. If a driver
writer wants to turn off all accel in the kernel driver, it can, its
In
Hi,
Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
Now, I'm quite sure the above framework could work quite well with any
OMAP like hardware, with unified memory (i.e. the video buffers are in
SDRAM) and 3D chips and similar components are separate. But what I'm
not sure
On Wed, Sep 21, 2011 at 8:01 AM, Tomi Valkeinen wrote:
> I don't know what MCS is.
MCS is manufacturer specific commands (Manufacturer Command Set).
> But DSI is just a bi-directional transfer
> protocol between the SoC and the peripheral, you can send arbitrary data
> over it.
>
> Normally the
Hi,
Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
> Now, I'm quite sure the above framework could work quite well with any
> OMAP like hardware, with unified memory (i.e. the video buffers are in
> SDRAM) and 3D chips and similar components are separate. But what I'm
> not
On Tue, 2011-09-20 at 23:20 +0200, Patrik Jakobsson wrote:
> Ok, not sure I understand the complexity of DSI. Can overlay composition
> occur after/at the DSI stage (through MCS perhaps)? Or is it a matter of
> panels requiring special scanout buffer formats that for instance V4L needs
> to know
t; V4L2_MEMORY_DMABUF), video encoder, etc.. the importing device should
> bracket DMA to/from the buffer w/ get/put_scatterlist() so an unused
> buffer could be unpinned if needed.
I second Rob here, I think that API should be enough to solve our memory
sharing problems between different devi
On Tue, Sep 20, 2011 at 5:55 PM, Keith Packard wrote:
> I'm not sure we need a new abstraction that subsumes both DSI and SDVO,
Ok. SDVO fits within the current abstraction, but I guess what I'm fishing
for is more code sharing of encoders. For instance, the SDVO code in GMA500
could be shared
On Tue, 2011-09-20 at 23:20 +0200, Patrik Jakobsson wrote:
Ok, not sure I understand the complexity of DSI. Can overlay composition
occur after/at the DSI stage (through MCS perhaps)? Or is it a matter of
panels requiring special scanout buffer formats that for instance V4L needs
to know
On Wed, Sep 21, 2011 at 8:01 AM, Tomi Valkeinen wrote:
I don't know what MCS is.
MCS is manufacturer specific commands (Manufacturer Command Set).
But DSI is just a bi-directional transfer
protocol between the SoC and the peripheral, you can send arbitrary data
over it.
Normally the SoC
On Mon, Sep 19, 2011 at 9:29 AM, Tomi Valkeinen wrote:
>> So DSI is more like i2c than the DisplayPort aux channel or DDC. That
>
> Well, not quite. DSI is like DisplayPort and DisplayPort aux combined;
> there's only one bus, DSI, which is used to transfer video data and
> commands.
>
> For DSI
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson wrote:
> It would be nice to have a model that fits both DSI and SDVO, and the option
> to configure some of it from userspace.
> I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is entirely hidden by the
On Mon, Sep 19, 2011 at 9:29 AM, Tomi Valkeinen wrote:
So DSI is more like i2c than the DisplayPort aux channel or DDC. That
Well, not quite. DSI is like DisplayPort and DisplayPort aux combined;
there's only one bus, DSI, which is used to transfer video data and
commands.
For DSI video
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson
patrik.r.jakobs...@gmail.com wrote:
It would be nice to have a model that fits both DSI and SDVO, and the option
to configure some of it from userspace.
I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is
On Tue, Sep 20, 2011 at 5:55 PM, Keith Packard wrote:
I'm not sure we need a new abstraction that subsumes both DSI and SDVO,
Ok. SDVO fits within the current abstraction, but I guess what I'm fishing
for is more code sharing of encoders. For instance, the SDVO code in GMA500
could be shared
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
> On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
> wrote:
>
> > I think it's a bit more complex than that. True, there are MIPI
> > standards, for the video there are DPI, DBI, DSI, and for the commands
> > there is DCS. And, as you
On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
> > 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.
>
> DSI and the various other MIPI bits tend to
Hi Rob,
(CC'ing linux-media, as I believe this is very on-topic)
On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
> On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
> > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> >> On 09/15/2011 05:52 PM, Alex Deucher
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
wrote:
> I think it's a bit more complex than that. True, there are MIPI
> standards, for the video there are DPI, DBI, DSI, and for the commands
> there is DCS. And, as you mentioned, many panels need custom
> initialization, or support only
> This would leave us with the issue of controlling formats and other
> parameters
> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state and
behaviour of memory, sequencing of accesses, cache control and
On Fri, 2011-09-16 at 17:53 +0100, Alan Cox wrote:
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.
DSI and the various other MIPI bits tend to be
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This would leave us with the issue of controlling formats and other
parameters
on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I think it's a bit more complex than that. True, there are MIPI
standards, for the video there are DPI, DBI, DSI, and for the commands
there is DCS. And, as you mentioned, many panels need custom
initialization,
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote:
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I think it's a bit more complex than that. True, there are MIPI
standards, for the video there are DPI, DBI, DSI, and for the commands
there is DCS.
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox wrote:
>> This would leave us with the issue of controlling formats and other
>> parameters
>> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
>
> There are some other differences that matter. The exact state and
> behaviour
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
>> On 09/15/2011 05:52 PM, Alex Deucher wrote:
>> >
>> > Please don't claim that the DRM developers do not want to cooperate.
>> > I realize that
Hi everybody,
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> On 09/15/2011 05:52 PM, Alex Deucher wrote:
> >
> > Please don't claim that the DRM developers do not want to cooperate.
> > I realize that people have strong opinions about existing APIs, put
> > there has
On Thursday 15 September 2011 19:05:00 Alan Cox wrote:
> On Thu, 15 Sep 2011 10:50:32 -0500
> Keith Packard wrote:
> > On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen wrote:
> > > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > > the plan is to make DRM the core Linux
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi everybody,
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
On 09/15/2011 05:52 PM, Alex Deucher wrote:
Please don't claim that the DRM developers do not want to cooperate.
Hi Rob,
(CC'ing linux-media, as I believe this is very on-topic)
On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
On 09/15/2011 05:52 PM, Alex Deucher wrote:
This would leave us with the issue of controlling formats and other
parameters
on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state and
behaviour of memory, sequencing of accesses, cache control and
> Just tell the X driver to not use acceleration, and it you won't get
> any acceleration used, then you get complete stability. If a driver
> writer wants to turn off all accel in the kernel driver, it can, its
In fact one thing we actually need really is a "dumb" KMS X server to
replace the
>
> Is it? Well, okay, I don't want to use any acceleration that can crash my
> machine, where can I select it, preferably as compile time option? I didn't
> find
> such a thing for Intel or Radeon. Don't say, I should rely on userspace here
> or
> use fbdev for this.
Just tell the X driver to
On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>
>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>> machine, where can I select it, preferably as compile time option? I didn't
>> find
>> such a thing for Intel or Radeon. Don't say, I should rely on userspace here
>> or
On 09/17/2011 04:47 PM, Dave Airlie wrote:
>>
>> I disagree. This depends on the functionality the hardware has, the desired
>> userspace and the manpower one has to do it. And of course if you just want
>> fb
>> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have
>> just
>
> I disagree. This depends on the functionality the hardware has, the desired
> userspace and the manpower one has to do it. And of course if you just want fb
> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have
> just
> an fb driver for devices that can't do more
On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox wrote:
>> One of my biggest problems with KMS is that it has (naturally) a lot more
>> complexity than the fb API which leads to instability. Basically it's very
>
> It shouldn't do - and a sample of one (your machine) is not a
> statistically valid set.
On Sat, Sep 17, 2011 at 3:06 PM, Florian Tobias Schandinat
wrote:
> On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>>
>>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>>> machine, where can I select it, preferably as compile time option? I didn't
>>> find
>>> such a
On 09/17/2011 03:16 PM, Rob Clark wrote:
>>From userspace perspective, fbdev doesn't go away. It is just a
> legacy interface provided on top of DRM/KMS driver mostly via helper
> functions. With this approach, you get the richer KMS API (and all
> the related plumbing for hotplug, EDID parsing,
On Sat, Sep 17, 2011 at 12:06 PM, Florian Tobias Schandinat
wrote:
> Again, you seem to not understand my reasoning. The "if" is the problem, it's
> the kernels job to ensure stability. Allowing the userspace to decide whether
> it
> crashes my machine is not acceptable to me.
> I do not claim
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
wrote:
> On 09/17/2011 03:16 PM, Rob Clark wrote:
>>>From userspace perspective, fbdev doesn't go away. ?It is just a
>> legacy interface provided on top of DRM/KMS driver mostly via helper
>> functions. ?With this approach, you get the
On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras
wrote:
> On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox wrote:
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a
On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
One of my biggest problems with KMS is that it has (naturally) a lot more
complexity than the fb API which leads to instability. Basically it's very
It shouldn't do - and a sample of one (your machine) is not a
On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
One of my biggest problems with KMS is that it has (naturally) a lot more
complexity than the fb API which leads to instability.
On 09/17/2011 03:16 PM, Rob Clark wrote:
From userspace perspective, fbdev doesn't go away. It is just a
legacy interface provided on top of DRM/KMS driver mostly via helper
functions. With this approach, you get the richer KMS API (and all
the related plumbing for hotplug, EDID parsing,
I disagree. This depends on the functionality the hardware has, the desired
userspace and the manpower one has to do it. And of course if you just want fb
having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have
just
an fb driver for devices that can't do more anyway.
And
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
On 09/17/2011 03:16 PM, Rob Clark wrote:
From userspace perspective, fbdev doesn't go away. It is just a
legacy interface provided on top of DRM/KMS driver mostly via helper
functions. With this
On 09/17/2011 04:47 PM, Dave Airlie wrote:
I disagree. This depends on the functionality the hardware has, the desired
userspace and the manpower one has to do it. And of course if you just want
fb
having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have
just
an fb
Is it? Well, okay, I don't want to use any acceleration that can crash my
machine, where can I select it, preferably as compile time option? I didn't
find
such a thing for Intel or Radeon. Don't say, I should rely on userspace here
or
use fbdev for this.
Just tell the X driver to not use
On 09/17/2011 06:23 PM, Dave Airlie wrote:
Is it? Well, okay, I don't want to use any acceleration that can crash my
machine, where can I select it, preferably as compile time option? I didn't
find
such a thing for Intel or Radeon. Don't say, I should rely on userspace here
or
use fbdev
On Sat, Sep 17, 2011 at 12:06 PM, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
Again, you seem to not understand my reasoning. The if is the problem, it's
the kernels job to ensure stability. Allowing the userspace to decide whether
it
crashes my machine is not acceptable to me.
Just tell the X driver to not use acceleration, and it you won't get
any acceleration used, then you get complete stability. If a driver
writer wants to turn off all accel in the kernel driver, it can, its
In fact one thing we actually need really is a dumb KMS X server to
replace the fbdev X
On Sat, Sep 17, 2011 at 3:06 PM, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
On 09/17/2011 06:23 PM, Dave Airlie wrote:
Is it? Well, okay, I don't want to use any acceleration that can crash my
machine, where can I select it, preferably as compile time option? I didn't
find
On Thursday 15 September 2011 19:05:00 Alan Cox wrote:
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display
Hi everybody,
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
On 09/15/2011 05:52 PM, Alex Deucher wrote:
Please don't claim that the DRM developers do not want to cooperate.
I realize that people have strong opinions about existing APIs, put
there has been just
> 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.
DSI and the various other MIPI bits tend to be horribly panel and device
specific. In one sense yes its a
On Thu, Sep 15, 2011 at 07:55:37PM -0500, Keith Packard wrote:
> 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
> devices.
This.
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> 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
Hi Tomi,
On Thu, Sep 15, 2011 at 9:07 PM, Tomi Valkeinen
wrote:
> Hi,
>
> I am the author of OMAP display driver, and while developing it I've
> often felt that there's something missing in Linux's display area. I've
> been planning to write a post about this for a few years already, but I
>
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen tomi.valkei...@ti.com
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
On Thu, Sep 15, 2011 at 07:55:37PM -0500, Keith Packard wrote:
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
devices.
This. Helper
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.
DSI and the various other MIPI bits tend to be horribly panel and device
specific. In one sense yes its a
> Okay, I see your problem. It's a bit strange you don't have acceleration. I
The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.
At some point I'll add hardware scrolling however by using the GTT to
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat
wrote:
> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally
> acceptable
> would be to split it of, probably as a standalone module and
> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.
GMA500 is basically a 2D or dumb frame buffer setup but with a lot of
rather complicated output and
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is
> What is your problem with discontigous framebuffers? (I assume discontigous
> refers to the pages the framebuffer is composed of)
> Sounds to me like you should implement your own fb_mmap and either map it
> contigous to screen_base or implement your own fb_read/write.
> In theory you could even
> Well, I rather think that the fb API is more user centric to allow every
> program
> to use it directly in contrast to the KMS/DRM API which aims to support every
> feature the hardware has. For this the fb API should not change much, but I
> understand some additions were needed for some
On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API. ?The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern
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
On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your
On 09/15/2011 06:58 PM, Alan Cox wrote:
>> Well, I rather think that the fb API is more user centric to allow every
>> program
>> to use it directly in contrast to the KMS/DRM API which aims to support every
>> feature the hardware has. For this the fb API should not change much, but I
>>
On 09/15/2011 05:52 PM, Alex Deucher wrote:
> On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
> wrote:
>> On 09/15/2011 03:50 PM, Keith Packard wrote:
>>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen >> ti.com> wrote:
>>>
1) It's part of DRM, so it doesn't help fb or v4l2
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
> wrote:
>
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
>
> Jesse Barnes has put together a proposal
> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.
There are aspects of the fb
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is
Hi Alan,
On 09/15/2011 05:18 PM, Alan Cox wrote:
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>>
On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and
On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 06:58 PM, Alan Cox wrote:
>>> Well, I rather think that the fb API is more user centric to allow every
>>> program
>>> to use it directly in contrast to the KMS/DRM API which aims to support
>>> every
>>> feature
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
wrote:
> On Thu, Sep 15, 2011 at 19:52, Alex Deucher wrote:
>> While the DRM has historically targeted 3D acceleration, that is not a
>> requirement to use the DRM KMS modesetting API. ?The current fb API
>> has no concept of display
On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
wrote:
> On 09/15/2011 03:50 PM, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>>> the plan is to make DRM the core
On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen
wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the
On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat
wrote:
> Interesting that this comes from the people that pushed the latest mode
> setting
> code into the kernel. But I don't think that this will happen, the exposed
> user
> interfaces will be around for decades and the
Wasn't there a driver for qemu cirrus "hardware"?
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>>
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
wrote:
> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.
I'd like to think we
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
wrote:
> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is
Hi,
I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!
---
First I want to (try to) describe
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
This was a very rough and quite short proposal, but I'm happy to improve
and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM
On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
This was a very rough and quite short proposal, but I'm happy to improve
and extend it if it's not totally shot down.
Jesse Barnes has put together a
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything else is built, and fb and v4l2 are changed to use DRM.
I'd
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard kei...@keithp.com wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon
On 09/15/2011 03:50 PM, Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything else is built,
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are
more
likely to diverge. At least I'll never accept any change to the fb
infrastructure that requires DRM.
There are aspects of the fb code
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything
Hi Alan,
On 09/15/2011 05:18 PM, Alan Cox wrote:
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are
more
likely to diverge. At least I'll never accept any change to the fb
infrastructure
On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
On 09/15/2011 03:50 PM, Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the
On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com wrote:
While the DRM has historically targeted 3D acceleration, that is not a
requirement to use the DRM KMS modesetting API. The current fb API
has no concept of display controllers or connectors or overlays, etc.
To match it
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com wrote:
While the DRM has historically targeted 3D acceleration, that is not a
requirement to use the DRM KMS modesetting API. The current fb API
1 - 100 of 114 matches
Mail list logo
