Hmm, I was thinking more on the xf86 side of things.. ie. to provide
default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec
functions..
BR,
-R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou jammy.z...@linaro.org wrote:
There is already one KMS abstraction layer (libkms.so) in libdrm,
I'm still in the learning-as-I-go phase here, so definitely not ready
to propose a solution, but it does seem to me like there is room for
some sort of kms-helper library here to handle more of the boilerplate
xf86-video-* stuff.. I guess I'll have a better picture once I have a
chance to
To accommodate the fact of independent display controller and GPU components
in ARM SOC, it will be better if we can separate KMS from DRM both in kernel
space and user space (i.e, create a new drivers/video/kms directory for
kernel side, move KMS related code in libdrm to libkms in user space).
I also noticed that default XRandR1.2+ implementation is missing in X side.
If we can implement one, it would be beneficial for all ARM platforms. By
the way, does X driver of TI support XRandR1.2+?
Regards,
Jammy
On Thu, Feb 17, 2011 at 11:25 PM, Clark, Rob r...@ti.com wrote:
Hmm, I was
I'm all for a more modular drm, although I think the framework of
CRTCs, encoders, and connectors is a nice fit, at least for our hw.
It would be nice to have a better way to expose overlays. And I'm
still thinking about how/if GEM fits in with our various video and
2/3d accelerators.
BR,
-R
On
I'm in the process of adding xrandr support to our xorg driver..
definitely more built-in support on the X side would make this easier.
BR,
-R
On Thu, Feb 17, 2011 at 8:25 PM, Jammy Zhou jammy.z...@linaro.org wrote:
I also noticed that default XRandR1.2+ implementation is missing in X side.
If
Speaking for the Linaro graphics working group, I think it's great. And, I
think you're right, that if enough of the KMS support in xf86-video-* is
similar enough (I was only aware of intel and nouveau supporting it properly
at current), pulling it out into a common layer would make it easier to
I'm still in the learning-as-I-go phase here, so definitely not ready
to propose a solution, but it does seem to me like there is room for
some sort of kms-helper library here to handle more of the boilerplate
xf86-video-* stuff.. I guess I'll have a better picture once I have a
chance to add
On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 09 February 2011, Sascha Hauer wrote:
The driver patch itself is Cced to linux-fbdev, only the introductory
mail is not.
Ok, I see.
Did you consider making the driver a KMS driver instead of
a frame buffer?
On Wed, Feb 09, 2011 at 05:31:07PM +0100, Arnd Bergmann wrote:
Ok. This sounds like a lot of upfront work indeed, to make KMS more
generic, though I think a number of driver would benefit from it
eventually. It could be something for the Linaro graphics working
group to look at in the
On Wednesday 09 February 2011, Sascha Hauer wrote:
The driver patch itself is Cced to linux-fbdev, only the introductory
mail is not.
Ok, I see.
Did you consider making the driver a KMS driver instead of
a frame buffer? I think the recommendation these days is
to start out with KMS for
11 matches
Mail list logo
