On Tue, Dec 07, 2010 at 07:47:28AM -0800, ext Keith Packard wrote:
On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä ville.syrj...@nokia.com
wrote:
Say, for example, that you have a portrait scanned LCD (which has it's
own memory) and TV out, and let's say you want everything to be in
On Mon, Dec 06, 2010 at 08:44:41AM -0800, ext Keith Packard wrote:
On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote:
Nope, we don't have any per-CRTC differences there, it's just that
rotation is essentially another property of the mode that we need to know
about
On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä ville.syrj...@nokia.com
wrote:
Say, for example, that you have a portrait scanned LCD (which has it's
own memory) and TV out, and let's say you want everything to be in
landscape all the time. The LCD could do the required 90/270 degree
Hi,
On Sun, Dec 05, 2010 at 06:15:04PM -0800, Keith Packard wrote:
On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com
wrote:
The actual text sounds reasonable to me, but it's not clear what the
'rotations' field of RRCreateScanoutPixmap is used for. Is it a set of
On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote:
Nope, we don't have any per-CRTC differences there, it's just that
rotation is essentially another property of the mode that we need to know
about in order to set up both the CRTC and the underlying surfaces,
rather
On Sun, Dec 05, 2010 at 08:47:15PM -0800, Keith Packard wrote:
On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com
wrote:
The crtc shadow functions seem obsolete given the new scanout pixmap
creation function, but they can be removed in a later ABI.
So, I was
On Sun, Dec 05, 2010 at 06:17:12PM -0800, Keith Packard wrote:
On Sun, 5 Dec 2010 16:42:43 -0800, Aaron Plattner aplatt...@nvidia.com
wrote:
Unless it's very generic or just a string to present to the user, I don't
think trying to encode this in the protocol is going to be reasonable. We
On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote:
On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote:
Nope, we don't have any per-CRTC differences there, it's just that
rotation is essentially another property of the mode that we need to know
about in
On Mon, 6 Dec 2010 09:42:24 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote:
On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org
wrote:
Nope, we don't have any per-CRTC differences there, it's just that
Yes, definitely. #2 seems easier. If you also turn on panning so the
whole screen area is accessible, then it seems better than #1 too because
the compositor is probably going to often be the window manager as well, so
#1 may still leave you with windows that you can't get to. As annoying
On Sat, Dec 04, 2010 at 03:06:35PM -0800, Keith Packard wrote:
To make per-crtc pixmaps actually useful for things like extended or
rotated desktops, I've added a couple of matrices to each crtc to
transform the sprite position and image. I suspect these will need
documentation beyond the
On Sat, Dec 04, 2010 at 08:34:40PM -0800, Keith Packard wrote:
Would it be useful to be able to return more information from the server
to the application? How would such information get encoded?
Unless it's very generic or just a string to present to the user, I don't
think trying to encode
On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
Thanks for reviewing over the weekend.
There are a few whitespace bugs, such as this:
┌───
RRQueryScanoutPixmaps
\twindow: WINDOW
▶
infos: LISTofSCANOUTPIXMAPINFO
└───
\tErrors: Window
I'll
On Sun, 5 Dec 2010 16:42:43 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
Unless it's very generic or just a string to present to the user, I don't
think trying to encode this in the protocol is going to be reasonable. We
have a bazillion ways that modesets can fail, most of which are due
On Sun, Dec 05, 2010 at 06:15:04PM -0800, Keith Packard wrote:
On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com
wrote:
Thanks for reviewing over the weekend.
There are a few whitespace bugs, such as this:
┌───
RRQueryScanoutPixmaps
\twindow: WINDOW
On Sun, 5 Dec 2010 22:47:21 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
Okay, I figured it was something like that. The actual hardware rotation
is configured when setting the crtc config then, right?
Right. The goal is to just expose what the hardware does and not fake
stuff in
To make per-crtc pixmaps actually useful for things like extended or
rotated desktops, I've added a couple of matrices to each crtc to
transform the sprite position and image. I suspect these will need
documentation beyond the following:
+┌───
+RRSetCrtcSpriteTransform
+ crtc: CRTC
+
I can't remember whether it was Aaron or Andy, but a couple of years ago
they talked about not being able to move the nVidia driver to RandR 1.2
because it didn't want to get the mode setting instructions in pieces.
Memory allocation and various hardware limits meant that there were many
18 matches
Mail list logo
