On Wed, 14 Dec 2011 07:20:13 -0800
Kevin Hilman wrote:
> Greg, Alan,
>
> Rajendra Nayak writes:
>
> > v3 is rebased on top of the latest serial runtime
> > patches[1] and boot tested with/without DT on OMAP4
> > SDP and OMAP4 Panda boards.
>
> With your ack on the drivers/tty/* stuff, I can q
> 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 mana
> 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 fbde
> 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 s
> 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
implemnent
> 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 me
> 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 specia
> 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 c
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 buil
> > 3. GMA500 used the old way of doing things because last mail conversation
> > I had with Hugh the cleaned up interfaces could not guarantee the page is
> > mapped in the low 32bits and for any of the GMA500/600 series devices.
> >
> > Has that changed ? I think I'd also prefer it if the methods
On Mon, 12 Sep 2011 14:21:26 -0500
Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
Generally looks sensible but:
1. This is a staging driver, so good practise is to cc the staging
maintainer and preferably the author (though I'm on dri-devel so its ok).
It needs to be co-ordi
> way to behave. The best way to get companies to change their behaviour is
> to find them and support them. Making threatening GPL noises in email does
> not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situati
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
I would suggest you re-read the license. It says nothing of the sort.
Indeed the gcc compiler licensing for the compiler support library is
actually rather care
> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,
Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which
> My point which people keep missing is that graphics stacks are a
> single entity, that span kernel and userspace, one cannot exist
> without the other, and there are interfaces that join them.
As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a deri
16 matches
Mail list logo
