Re: [PATCH xserver] Xmir DDX
On Fri, Apr 29, 2016 at 5:31 PM Julien Cristau wrote: > On Fri, Apr 29, 2016 at 15:25:40 +0000, Robert Ancell wrote: > > > On Fri, Apr 29, 2016 at 4:47 PM Adam Jackson wrote: > > > > Your footnotes seem to have gone missing. > > > > > > > Not sure what you mean by footnotes? > > > The [2] and [3] dangling references above. > Oh, sorry. My git send-email attempts have failed me :( Also missed the first line: Find attached a patch for XMir - a DDX that allows Xorg to run on a Mir [1] display server. [1] https://wiki.ubuntu.com/Mir [2] http://www.ubuntu.com/tablet/devices [3] https://code.launchpad.net/~xmir-team/xorg-server/+git/xmir ___ 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] Xmir DDX
On Fri, Apr 29, 2016 at 4:47 PM Adam Jackson wrote: > On Fri, 2016-04-29 at 11:11 +0200, Robert Ancell wrote: > > This is currently used in Ubuntu to allow X applications and sessions to > run in > > newer versions of Unity 8. For example, this allows applications like > GIMP to > > run on mobile devices like the Bq Aquaris M10 [2] (currently shipping). > > > > The proposed patch allows software based rendering only. The XMir used > in Ubuntu > > contains more changes (developed on Launchpad [3]) that are unlikely to > be of > > sufficient quality for proposal upstream. We will propose those changes > when > > they are ready. > > Your footnotes seem to have gone missing. > Not sure what you mean by footnotes? > I'm not a huge fan of seeing the cvt code duplicated yet again. Seems > like we should just add this to RANDR already. Also not a huge fan of > some of the extremely long lines, but maybe I'm just stuck in an 80 > column mindset. > Yeah, would love to drop the duplication. Very happy to integrate if someone makes it available! I'm happy to refactor the long lines if that fits in better with the exisitng X code. > > Can you point me in the direction of what provides the new pkgconfig > modules mentioned? If this is going to land I'm going to want to be > able to build it. > Do you mean mirclient and mir-client-platform-mesa? These are both provided by Mir which is developed on Launchpad [1] with code in bzr and tarballs available for download. [1] https://launchpad.net/mir Thanks, --Robert ___ 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] Xmir DDX
The following email with the patch is just over 100k in size and thus is stuck in the moderation queue.. On Fri, Apr 29, 2016 at 11:11 AM Robert Ancell wrote: > This is currently used in Ubuntu to allow X applications and sessions to > run in > newer versions of Unity 8. For example, this allows applications like GIMP > to > run on mobile devices like the Bq Aquaris M10 [2] (currently shipping). > > The proposed patch allows software based rendering only. The XMir used in > Ubuntu > contains more changes (developed on Launchpad [3]) that are unlikely to be > of > sufficient quality for proposal upstream. We will propose those changes > when > they are ready. > > Thanks, > --Robert > > Robert Ancell (1): > XMir DDX > > configure.ac| 24 + > hw/Makefile.am |9 +- > hw/xmir/.gitignore |1 + > hw/xmir/Makefile.am | 27 + > hw/xmir/xmir-cursor.c | 210 +++ > hw/xmir/xmir-cvt.c | 304 ++ > hw/xmir/xmir-input.c| 592 ++ > hw/xmir/xmir-output.c | 424 + > hw/xmir/xmir-thread-proxy.c | 109 > hw/xmir/xmir.c | 1416 > +++ > hw/xmir/xmir.h | 165 + > 11 files changed, 3279 insertions(+), 2 deletions(-) > create mode 100644 hw/xmir/.gitignore > create mode 100644 hw/xmir/Makefile.am > create mode 100644 hw/xmir/xmir-cursor.c > create mode 100644 hw/xmir/xmir-cvt.c > create mode 100644 hw/xmir/xmir-input.c > create mode 100644 hw/xmir/xmir-output.c > create mode 100644 hw/xmir/xmir-thread-proxy.c > create mode 100644 hw/xmir/xmir.c > create mode 100644 hw/xmir/xmir.h > > -- > 2.7.4 > > ___ 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
[PATCH xserver] Xmir DDX
This is currently used in Ubuntu to allow X applications and sessions to run in newer versions of Unity 8. For example, this allows applications like GIMP to run on mobile devices like the Bq Aquaris M10 [2] (currently shipping). The proposed patch allows software based rendering only. The XMir used in Ubuntu contains more changes (developed on Launchpad [3]) that are unlikely to be of sufficient quality for proposal upstream. We will propose those changes when they are ready. Thanks, --Robert Robert Ancell (1): XMir DDX configure.ac| 24 + hw/Makefile.am |9 +- hw/xmir/.gitignore |1 + hw/xmir/Makefile.am | 27 + hw/xmir/xmir-cursor.c | 210 +++ hw/xmir/xmir-cvt.c | 304 ++ hw/xmir/xmir-input.c| 592 ++ hw/xmir/xmir-output.c | 424 + hw/xmir/xmir-thread-proxy.c | 109 hw/xmir/xmir.c | 1416 +++ hw/xmir/xmir.h | 165 + 11 files changed, 3279 insertions(+), 2 deletions(-) create mode 100644 hw/xmir/.gitignore create mode 100644 hw/xmir/Makefile.am create mode 100644 hw/xmir/xmir-cursor.c create mode 100644 hw/xmir/xmir-cvt.c create mode 100644 hw/xmir/xmir-input.c create mode 100644 hw/xmir/xmir-output.c create mode 100644 hw/xmir/xmir-thread-proxy.c create mode 100644 hw/xmir/xmir.c create mode 100644 hw/xmir/xmir.h -- 2.7.4 ___ 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
[PATCH xf86-video-intel] uxa: Add missing const to string to stop compiler warning
--- src/uxa/intel_hwmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/uxa/intel_hwmc.c b/src/uxa/intel_hwmc.c index 829cb8e..7854060 100644 --- a/src/uxa/intel_hwmc.c +++ b/src/uxa/intel_hwmc.c @@ -193,7 +193,7 @@ Bool intel_xvmc_adaptor_init(ScreenPtr pScreen) intel_screen_private *intel = intel_get_screen_private(scrn); struct pci_device *pci; static XF86MCAdaptorRec *pAdapt; - char *name; + const char *name; char buf[64]; if (!intel->XvMCEnabled) -- 2.5.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Stop accessing the attribute array using the attribute name enum.
This was found when compiling for aarch64 (PowerPC):
../../src/smi_video.c: In function 'SMI_ResetVideo':
../../src/smi_video.c:686:45: error: array subscript is above array bounds
[-Werror=array-bounds]
value = CLAMP(value, SMI_VideoAttributes[i].min_value,
I'm not sure why the other architectures don't pick this up.
--Robert
On Wed, Sep 30, 2015 at 5:02 PM Robert Ancell
wrote:
> The array has only two elements but the clamping code was assuming it
> contained
> all the elements in order. This means no clamping is now done but at least
> it
> wont read off the end of the array.
>
> Signed-off-by: Robert Ancell
> ---
> src/smi_video.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/src/smi_video.c b/src/smi_video.c
> index 27df68d..a13668e 100644
> --- a/src/smi_video.c
> +++ b/src/smi_video.c
> @@ -681,10 +681,6 @@ SetAttr(ScrnInfoPtr pScrn, int i, int value)
>
> if (i < XV_ENCODING || i > XV_HUE)
> return BadMatch;
> -
> -/* clamps value to attribute range */
> -value = CLAMP(value, SMI_VideoAttributes[i].min_value,
> - SMI_VideoAttributes[i].max_value);
>
> if (i == XV_BRIGHTNESS) {
> int my_value = (value <= 128? value + 128 : value - 128);
> --
> 2.5.0
>
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Stop accessing the attribute array using the attribute name enum.
The array has only two elements but the clamping code was assuming it contained
all the elements in order. This means no clamping is now done but at least it
wont read off the end of the array.
Signed-off-by: Robert Ancell
---
src/smi_video.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/smi_video.c b/src/smi_video.c
index 27df68d..a13668e 100644
--- a/src/smi_video.c
+++ b/src/smi_video.c
@@ -681,10 +681,6 @@ SetAttr(ScrnInfoPtr pScrn, int i, int value)
if (i < XV_ENCODING || i > XV_HUE)
return BadMatch;
-
-/* clamps value to attribute range */
-value = CLAMP(value, SMI_VideoAttributes[i].min_value,
- SMI_VideoAttributes[i].max_value);
if (i == XV_BRIGHTNESS) {
int my_value = (value <= 128? value + 128 : value - 128);
--
2.5.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] Remove non-existant dst-x, dst-y fields from CompositeGlyphs* requests
Signed-off-by: Robert Ancell --- renderproto.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/renderproto.txt b/renderproto.txt index 14ff15d..c349e03 100644 --- a/renderproto.txt +++ b/renderproto.txt @@ -986,7 +986,6 @@ CompositeGlyphs32 mask-format:PICTFORMAT or None glyphset: GLYPHABLE src-x, src-y: INT16 - dst-x, dst-y: INT16 glyphcmds: LISTofGLYPHITEM8CompositeGlyphs8 glyphcmds: LISTofGLYPHITEM16 CompositeGlyphs16 glyphcmds: LISTofGLYPHITEM32 CompositeGlyphs32 @@ -994,7 +993,7 @@ CompositeGlyphs32 Errors: Picture, PictOp, PictFormat, GlyphSet, Glyph - The dst-x and dst-y coordinates are relative to the drawable's + The src-x and src-y coordinates are relative to the drawable's origin and specify the baseline starting position (the initial glyph origin). Each glyph item is processed in turn. A glyphset item causes the glyphset to be used for subsequent glyphs. Switching -- 2.5.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] modesetting: Use correct datatypes for return values from glamor_name_from_pixmap and glamor_fd_from_pixmap
glamor_name_from_pixmap and glamor_fd_from_pixmap return CARD16 and CARD32
values via pointers.
The current code uses uint16_t and uint32_t which will probably be the same but
it's safer to use
the datatypes as specified by the function.
Signed-off-by: Robert Ancell
---
hw/xfree86/drivers/modesetting/dri2.c| 4 ++--
hw/xfree86/drivers/modesetting/drmmode_display.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/dri2.c
b/hw/xfree86/drivers/modesetting/dri2.c
index 63cb065..0fe420c 100644
--- a/hw/xfree86/drivers/modesetting/dri2.c
+++ b/hw/xfree86/drivers/modesetting/dri2.c
@@ -138,8 +138,8 @@ ms_dri2_create_buffer(DrawablePtr drawable, unsigned int
attachment,
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
DRI2Buffer2Ptr buffer;
PixmapPtr pixmap;
-uint32_t size;
-uint16_t pitch;
+CARD32 size;
+CARD16 pitch;
ms_dri2_buffer_private_ptr private;
buffer = calloc(1, sizeof *buffer);
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index ef5b087..6a13660 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -148,8 +148,8 @@ drmmode_bo_for_pixmap(drmmode_ptr drmmode, drmmode_bo *bo,
PixmapPtr pixmap)
{
#ifdef GLAMOR
ScreenPtr screen = xf86ScrnToScreen(drmmode->scrn);
-uint16_t pitch;
-uint32_t size;
+CARD16 pitch;
+CARD32 size;
int fd;
#ifdef GLAMOR_HAS_GBM
--
2.1.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] randrproto: remove duplicate definition of Atom type
The Atom type was defined a second time with the 1.5 changes. It was already
previously defined to be a CARD32.
Signed-off-by: Robert Ancell
---
randrproto.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/randrproto.h b/randrproto.h
index 114a624..48be7aa 100644
--- a/randrproto.h
+++ b/randrproto.h
@@ -50,7 +50,6 @@
#define RRCrtc CARD32
#define RRProvider CARD32
#define RRModeFlags CARD32
-#define Atom CARD32
#define Rotation CARD16
#define SizeID CARD16
@@ -1091,6 +1090,5 @@ typedef struct {
#undef Rotation
#undef SizeID
#undef SubpixelOrder
-#undef Atom
#endif /* _XRANDRP_H_ */
--
2.1.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xwayland: Fix error strings
Fix missing newlines from error string and fix grammar.
Signed-off-by: Robert Ancell
---
hw/xwayland/xwayland-glamor.c | 4 ++--
hw/xwayland/xwayland-input.c | 2 +-
hw/xwayland/xwayland-output.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index d06006c..6b6e597 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -310,7 +310,7 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen)
}
if (!epoxy_has_gl_extension("GL_OES_EGL_image")) {
-ErrorF("GL_OES_EGL_image no available");
+ErrorF("GL_OES_EGL_image not available\n");
return;
}
@@ -329,7 +329,7 @@ xwl_drm_handle_device(void *data, struct wl_drm *drm, const
char *device)
xwl_screen->drm_fd = open(xwl_screen->device_name, O_RDWR | O_CLOEXEC);
if (xwl_screen->drm_fd == -1) {
- ErrorF("wayland-egl: could not open %s (%s)",
+ ErrorF("wayland-egl: could not open %s (%s)\n",
xwl_screen->device_name, strerror(errno));
return;
}
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index cc3bc53..488b839 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -561,7 +561,7 @@ create_input_device(struct xwl_screen *xwl_screen, uint32_t
id)
xwl_seat = calloc(sizeof *xwl_seat, 1);
if (xwl_seat == NULL) {
-ErrorF("create_input ENOMEM");
+ErrorF("create_input ENOMEM\n");
return;
}
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 778914c..155cbc1 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -159,7 +159,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t
id)
xwl_output = calloc(sizeof *xwl_output, 1);
if (xwl_output == NULL) {
-ErrorF("create_output ENOMEM");
+ErrorF("create_output ENOMEM\n");
return NULL;
}
@@ -168,7 +168,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t
id)
wl_output_add_listener(xwl_output->output, &output_listener, xwl_output);
if (snprintf(name, sizeof name, "XWAYLAND%d", serial++) < 0) {
-ErrorF("create_output ENOMEM");
+ErrorF("create_output ENOMEM\n");
free(xwl_output);
return NULL;
}
--
2.1.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] render: Don't generate invalid pixman format when using a 24bpp framebuffer with a 32bit depth visual.
Thanks for the reviews and finding the right place to fix this. --Robert On Fri, Aug 22, 2014 at 5:20 PM, Takashi Iwai wrote: > At Thu, 21 Aug 2014 20:13:48 -0500, > Keith Packard wrote: >> >> Takashi Iwai writes: >> >> >> > Meanwhile, fbCreatePixmap() has a more check and it creates with 24bpp >> > only when the passed depth <= 24 for avoiding such a problem. >> > >> > This oneliner patch just adds the similar check in fbCreateWindow(). >> > This (hopefully) fixes the long-standing broken graphics mess of >> > cirrus KMS with 24bpp. >> >> Merged. >>5d13327..fe5018e master -> master > > Thanks! > > > Takashi ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] fb: Correctly implement CopyArea when using a window with depth 32 and 24bpp.
This fixes gnome-terminal not showing in qemu [1] and can be triggered
by the attached test case.
I haven't combined this with the patch in [2] because this patch is
internally coherent with the fb logic; I still don't know if fb is
doing the right thing here by allowing depth=32 bpp=24. The RENDER
patch is not required for gnome-terminal (and I suspect any
application using depth 32 visual and cairo/GTK+ to render) but
follows the same logic.
--Robert
[1] http://lists.x.org/archives/xorg-devel/2014-June/042723.html
[2] http://lists.x.org/archives/xorg-devel/2014-June/042721.html
On Fri, Jun 6, 2014 at 11:52 PM, Robert Ancell
wrote:
> When using the fb backend at 24bpp it allows a visual with 32 bit depth.
> When using CopyArea from a 32bpp pixmap to a window with a 32 bit depth it
> would
> read the ARGB as RGB.
>
> Fix is to correctly ignore the alpha channel in the pixmap when copying.
> ---
> fb/fbcopy.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fb/fbcopy.c b/fb/fbcopy.c
> index 541ef71..5455947 100644
> --- a/fb/fbcopy.c
> +++ b/fb/fbcopy.c
> @@ -242,8 +242,16 @@ fbCopyArea(DrawablePtr pSrcDrawable,
> int xIn, int yIn, int widthSrc, int heightSrc, int xOut, int yOut)
> {
> miCopyProc copy;
> +int src_bpp, dst_bpp;
>
> -if (pSrcDrawable->bitsPerPixel != pDstDrawable->bitsPerPixel)
> +src_bpp = pSrcDrawable->bitsPerPixel;
> +if (src_bpp < pSrcDrawable->depth)
> +src_bpp = BitsPerPixel (pSrcDrawable->depth);
> +dst_bpp = pDstDrawable->bitsPerPixel;
> +if (dst_bpp < pDstDrawable->depth)
> +dst_bpp = BitsPerPixel (pDstDrawable->depth);
> +
> +if (src_bpp != dst_bpp)
> copy = fb24_32CopyMtoN;
> else
> copy = fbCopyNtoN;
> --
> 2.0.0
>
// gcc -g -Wall copy-area.c -o copy-area -lxcb
#include
#include
int main (int argc, char **argv)
{
xcb_connection_t *c = xcb_connect (NULL, NULL);
xcb_screen_t *screen = xcb_setup_roots_iterator (xcb_get_setup (c)).data;
xcb_visualtype_t *visual = NULL;
xcb_depth_iterator_t depth_iter = xcb_screen_allowed_depths_iterator (screen);
int depth = 32;
while (depth_iter.rem > 0)
{
if (depth_iter.data->depth == depth)
{
visual = xcb_depth_visuals (depth_iter.data);
break;
}
xcb_depth_next (&depth_iter);
}
uint16_t width = 50;
uint16_t height = 50;
xcb_colormap_t cmap = xcb_generate_id (c);
xcb_create_colormap (c, 0, cmap, screen->root, visual->visual_id);
xcb_window_t w = xcb_generate_id (c);
uint32_t value_list[4] = { screen->black_pixel, screen->black_pixel, XCB_EVENT_MASK_EXPOSURE, cmap };
xcb_create_window (c, depth,
w, screen->root,
0, 0, width, height, 0,
XCB_WINDOW_CLASS_INPUT_OUTPUT,
visual->visual_id,
XCB_CW_BACK_PIXEL | XCB_CW_BORDER_PIXEL | XCB_CW_EVENT_MASK | XCB_CW_COLORMAP,
value_list);
xcb_map_window (c, w);
xcb_pixmap_t p = xcb_generate_id (c);
xcb_create_pixmap (c, depth, p, w, width, height);
uint32_t data_length = width * height * sizeof (uint32_t);
uint32_t *data = malloc (data_length);
int x, y, i = 0;
// Asuming ARGB
for (x = 0; x < width; x++)
for (y = 0; y < height; y++)
data[i++] = (0xFF << 24) | ((x * 0xFF / width) << 16) | ((y * 0xFF / height) << 8);
xcb_gcontext_t gc = xcb_generate_id (c);
xcb_create_gc (c, gc, p, 0, NULL);
xcb_put_image (c, XCB_IMAGE_FORMAT_Z_PIXMAP, p, gc, width, height, 0, 0, 0, depth, data_length, (uint8_t *) data);
xcb_free_gc (c, gc);
xcb_flush (c);
gc = xcb_generate_id (c);
xcb_create_gc (c, gc, w, 0, NULL);
while (1)
{
xcb_generic_event_t *event = xcb_wait_for_event (c);
if (event == NULL)
break;
if (event->response_type == XCB_EXPOSE)
{
xcb_copy_area (c, p, w, gc, 0, 0, 0, 0, width, height);
xcb_flush (c);
}
}
return 0;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] fb: Correctly implement CopyArea when using a window with depth 32 and 24bpp.
When using the fb backend at 24bpp it allows a visual with 32 bit depth.
When using CopyArea from a 32bpp pixmap to a window with a 32 bit depth it would
read the ARGB as RGB.
Fix is to correctly ignore the alpha channel in the pixmap when copying.
---
fb/fbcopy.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fb/fbcopy.c b/fb/fbcopy.c
index 541ef71..5455947 100644
--- a/fb/fbcopy.c
+++ b/fb/fbcopy.c
@@ -242,8 +242,16 @@ fbCopyArea(DrawablePtr pSrcDrawable,
int xIn, int yIn, int widthSrc, int heightSrc, int xOut, int yOut)
{
miCopyProc copy;
+int src_bpp, dst_bpp;
-if (pSrcDrawable->bitsPerPixel != pDstDrawable->bitsPerPixel)
+src_bpp = pSrcDrawable->bitsPerPixel;
+if (src_bpp < pSrcDrawable->depth)
+src_bpp = BitsPerPixel (pSrcDrawable->depth);
+dst_bpp = pDstDrawable->bitsPerPixel;
+if (dst_bpp < pDstDrawable->depth)
+dst_bpp = BitsPerPixel (pDstDrawable->depth);
+
+if (src_bpp != dst_bpp)
copy = fb24_32CopyMtoN;
else
copy = fbCopyNtoN;
--
2.0.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] render: Don't generate invalid pixman format when using a 24bpp framebuffer with a 32bit depth visual.
Some background on this patch:
I've been trying to investigate why gnome-terminal doesn't render
correctly when running Ubuntu 14.04 LTS inside qemu (on Ubuntu 14.10).
The window is compressed in the X axis and has transparency (seems to
be a buffer somewhere that is being written in RGB and read as RGBA).
The issue seems to be GTK+ applications using the RGBA visual when
qemu/X/fb is providing a depth 24 root window. Playing around with
test cases showed the assertion mentioned in the patch. I'm not sure
if fb should be allowed to have a depth greater than the bpp and if
the bug is actually there but this patch allows correct rendering in
my test case now. I guess the Picture is being converted from RGBA to
RGB when it hits the root window?
Note this patch doesn't fix the gnome-terminal rendering issue, so
I'll continue down the rabbit hole. Any suggestions as to the causes
of this are greatly appreciated.
Attached is a program that doesn't render on the current master and
does with the applied patch.
--Robert
On Fri, Jun 6, 2014 at 4:36 PM, Robert Ancell
wrote:
> When using the fb backend at 24bpp it allows a visual with 32 bit depth.
> This would cause RENDER to try and create an invalid pixman buffer and hit the
> following assertion when trying to render to it:
>
> *** BUG ***
> In create_bits_image_internal: The expression PIXMAN_FORMAT_BPP (format) >=
> PIXMAN_FORMAT_DEPTH (format) was false
> Set a breakpoint on '_pixman_log_error' to debug
>
> Fix is to ensure that the bpp is always at least as big as the drawable depth.
> ---
> render/picture.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/render/picture.c b/render/picture.c
> index 7da9310..f411521 100644
> --- a/render/picture.c
> +++ b/render/picture.c
> @@ -762,6 +762,7 @@ CreatePicture(Picture pid,
> {
> PicturePtr pPicture;
> PictureScreenPtr ps = GetPictureScreen(pDrawable->pScreen);
> +int bpp;
>
> pPicture = dixAllocateScreenObjectWithPrivates(pDrawable->pScreen,
> PictureRec,
> PRIVATE_PICTURE);
> @@ -773,7 +774,10 @@ CreatePicture(Picture pid,
> pPicture->id = pid;
> pPicture->pDrawable = pDrawable;
> pPicture->pFormat = pFormat;
> -pPicture->format = pFormat->format | (pDrawable->bitsPerPixel << 24);
> +bpp = pDrawable->bitsPerPixel;
> +if (bpp < pFormat->depth)
> +bpp = BitsPerPixel (pFormat->depth);
> +pPicture->format = pFormat->format | (bpp << 24);
>
> /* security creation/labeling check */
> *error = XaceHook(XACE_RESOURCE_ACCESS, client, pid, PictureType,
> pPicture,
> --
> 2.0.0
>
// gcc -g -Wall test24.c -o test24 -lxcb -lxcb-render
#include
#include
int main (int argc, char **argv)
{
xcb_connection_t *c = xcb_connect (NULL, NULL);
xcb_screen_t *screen = xcb_setup_roots_iterator (xcb_get_setup (c)).data;
xcb_visualtype_t *visual = NULL;
xcb_depth_iterator_t depth_iter = xcb_screen_allowed_depths_iterator (screen);
int depth = 32;
while (depth_iter.rem > 0)
{
if (depth_iter.data->depth == depth)
{
visual = xcb_depth_visuals (depth_iter.data);
break;
}
xcb_depth_next (&depth_iter);
}
uint16_t width = 200;
uint16_t height = 100;
xcb_colormap_t cmap = xcb_generate_id (c);
xcb_create_colormap (c, 0, cmap, screen->root, visual->visual_id);
xcb_window_t w = xcb_generate_id (c);
uint32_t value_list[4] = { screen->black_pixel, screen->black_pixel, XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_STRUCTURE_NOTIFY, cmap };
xcb_create_window (c, depth,
w, screen->root,
0, 0, width, height, 0,
XCB_WINDOW_CLASS_INPUT_OUTPUT,
visual->visual_id,
XCB_CW_BACK_PIXEL | XCB_CW_BORDER_PIXEL | XCB_CW_EVENT_MASK | XCB_CW_COLORMAP,
value_list);
xcb_map_window (c, w);
xcb_render_query_pict_formats_reply_t *r = xcb_render_query_pict_formats_reply (c, xcb_render_query_pict_formats (c), NULL);
xcb_render_pictforminfo_iterator_t format_iter = xcb_render_query_pict_formats_formats_iterator (r);
xcb_render_pictformat_t format;
while (format_iter.rem > 0)
{
if (format_iter.data->depth == depth)
{
format = format_iter.data->id;
break;
}
xcb_render_pictforminfo_next (&format_iter);
}
xcb_render_picture_t pf = xcb_generate_id (c);
xcb_render_color_t color = { 65535, 0, 0, 65535 };
xcb_render_create_solid_fill (c, pf, color);
xcb_render_picture_t p = xcb_generate_id (c);
xcb_render_create_picture (c,
[PATCH] render: Don't generate invalid pixman format when using a 24bpp framebuffer with a 32bit depth visual.
When using the fb backend at 24bpp it allows a visual with 32 bit depth.
This would cause RENDER to try and create an invalid pixman buffer and hit the
following assertion when trying to render to it:
*** BUG ***
In create_bits_image_internal: The expression PIXMAN_FORMAT_BPP (format) >=
PIXMAN_FORMAT_DEPTH (format) was false
Set a breakpoint on '_pixman_log_error' to debug
Fix is to ensure that the bpp is always at least as big as the drawable depth.
---
render/picture.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/render/picture.c b/render/picture.c
index 7da9310..f411521 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -762,6 +762,7 @@ CreatePicture(Picture pid,
{
PicturePtr pPicture;
PictureScreenPtr ps = GetPictureScreen(pDrawable->pScreen);
+int bpp;
pPicture = dixAllocateScreenObjectWithPrivates(pDrawable->pScreen,
PictureRec,
PRIVATE_PICTURE);
@@ -773,7 +774,10 @@ CreatePicture(Picture pid,
pPicture->id = pid;
pPicture->pDrawable = pDrawable;
pPicture->pFormat = pFormat;
-pPicture->format = pFormat->format | (pDrawable->bitsPerPixel << 24);
+bpp = pDrawable->bitsPerPixel;
+if (bpp < pFormat->depth)
+bpp = BitsPerPixel (pFormat->depth);
+pPicture->format = pFormat->format | (bpp << 24);
/* security creation/labeling check */
*error = XaceHook(XACE_RESOURCE_ACCESS, client, pid, PictureType, pPicture,
--
2.0.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] dri2proto: Fix fields in SwapBuffers
Fix errors in SwapBuffers: - The section in "8. Extension Requests" was missing the target_msc, divisor and remainder fields - The section in "A.2 Protocol Requests" had two entries for SwapBuffers, both incorrect --- dri2proto.txt | 30 ++ 1 file changed, 6 insertions(+), 24 deletions(-) diff --git a/dri2proto.txt b/dri2proto.txt index 9921301..d81b55c 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -327,8 +327,11 @@ The name of this extension is "DRI2". ┌─── DRI2SwapBuffers drawable: DRAWABLE - ▶ - count: two CARD32s + target_msc: two CARD32s + divisor: two CARD32s + remainder: two CARD32s + ▶ + swap: two CARD32s └─── Errors: Window @@ -750,27 +753,6 @@ A.2 Protocol Requests 1 8 DRI2 opcode 2 8 length 4 DRAWABLEdrawable - ▶ - 1 1 Reply -1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 buffer count - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 5n LISTofDRI2BUFFERbuffers -└─── - -┌─── -DRI2SwapBuffers - 1 CARD8 major opcode - 1 8 DRI2 opcode - 2 8 length - 4 DRAWABLEdrawable 4 CARD32 target_msc_hi 4 CARD32 target_msc_lo 4 CARD32 divisor_hi @@ -784,7 +766,7 @@ A.2 Protocol Requests 4 0 reply length 4 CARD32 swap_hi 4 CARD32 swap_lo - 5n LISTofDRI2BUFFERbuffers + 20 unused └─── ┌─── -- 2.0.0.rc0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Fix overflow checking extension versions
I changed it to 32 bits because (at least) RANDR uses 32 bits for each
version number [1]:
RRQueryVersion
client-major-version: CARD32
client-minor-version: CARD32
▶
major-version: CARD32
minor-version: CARD32
This was the request I was sending where X said it supported RANDR
4294967295.4294967295.
[1] http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
On Fri, May 23, 2014 at 1:05 PM, Keith Packard wrote:
> Robert Ancell writes:
>
>> The easiest way to check for the version of an extension is to send the
>> maximum
>> possible version numbers in the QueryVersion request. The X server overflows
>> on
>> these as it assumes you will send a reasonable version number.
>> ---
>> include/misc.h | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/misc.h b/include/misc.h
>> index 17de710..9c2f573 100644
>> --- a/include/misc.h
>> +++ b/include/misc.h
>> @@ -259,15 +259,19 @@ extern void FormatDouble(double dbl, char *string);
>> * or a value greater than 0
>> */
>> static inline int
>> -version_compare(uint16_t a_major, uint16_t a_minor,
>> -uint16_t b_major, uint16_t b_minor)
>> +version_compare(uint32_t a_major, uint32_t a_minor,
>> +uint32_t b_major, uint32_t b_minor)
>
> I don't see any particular reason to change the signature of this
> function; the rest of the rewrite should work with 16-bit ints.
>
>> {
>> -int a, b;
>
> Just changing these to uint32_t and fixing the test to
>
> if (a > b)
> return 1;
> if (a < b)
> return -1;
> return 0;
>
> would suffice, assuming everything is 16-bit ints.
>
> --
> keith.pack...@intel.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Fix overflow checking extension versions
The easiest way to check for the version of an extension is to send the maximum
possible version numbers in the QueryVersion request. The X server overflows on
these as it assumes you will send a reasonable version number.
---
include/misc.h | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/misc.h b/include/misc.h
index 17de710..9c2f573 100644
--- a/include/misc.h
+++ b/include/misc.h
@@ -259,15 +259,19 @@ extern void FormatDouble(double dbl, char *string);
* or a value greater than 0
*/
static inline int
-version_compare(uint16_t a_major, uint16_t a_minor,
-uint16_t b_major, uint16_t b_minor)
+version_compare(uint32_t a_major, uint32_t a_minor,
+uint32_t b_major, uint32_t b_minor)
{
-int a, b;
+if (a_major > b_major)
+return 1;
+if (a_major < b_major)
+return -1;
+if (a_minor > b_minor)
+return 1;
+if (a_minor < b_minor)
+return -1;
-a = a_major << 16 | a_minor;
-b = b_major << 16 | b_minor;
-
-return (a - b);
+return 0;
}
/* some macros to help swap requests, replies, and events */
--
2.0.0.rc0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] Document QueryFilters
QueryFilters had no documentation. Document it, in particular how to interpret the 'aliases' field. --- renderproto.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/renderproto.txt b/renderproto.txt index 74fb411..14ff15d 100644 --- a/renderproto.txt +++ b/renderproto.txt @@ -567,7 +567,13 @@ QueryFilters filters:LISTofSTRING8 aliases:LISTofCARD16 - + This request gets the names of available filters that can be used on the + given drawable. Filters are applied using a SetPictureFilter request. + + 'aliases' contains a value for each filter name which is the index into + 'filters' if this name is an alias. Non-aliased filter have this value + set to 0x. + 14. Extension Requests CreatePicture -- 2.0.0.rc0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Correct QueryPictFormats reply fields.
The QueryPictFormats reply referred to a fallback which does not exist and didn't document the ndepths and nvisuals fields. --- renderproto.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/renderproto.txt b/renderproto.txt index 9f1f231..74fb411 100644 --- a/renderproto.txt +++ b/renderproto.txt @@ -519,9 +519,10 @@ QueryPictFormats -> - fallback: PICTFORMAT formats:LISTofPICTFORMINFO screens:LISTofPICTSCREEN + ndepths:CARD32 + nvisuals: CARD32 subpixels: LISTofSUBPIXEL Errors: @@ -532,8 +533,8 @@ QueryPictFormats Every PictFormat must match a supported depth, but not every PictFormat need have a matching visual. - The fallback format is used as an intermediate representation - in cases where there is no ideal choice. + The total number of PICTDEPTH and PICTVISUAL objects is this reply + is given in 'ndepths' and 'nvisuals'. The relationship between the red, green and blue elements making up each pixel indexed by screen is returned in subpixels. -- 2.0.0.rc0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] os: Add -displayfd into -help text
Add -displayfd into -help text. It was mentioned in the man page but seem to
have been missed from the -help text.
---
os/utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/os/utils.c b/os/utils.c
index 60e828e..1555dbd 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -501,6 +501,7 @@ UseMsg(void)
ErrorF("-cc intdefault color visual class\n");
ErrorF("-nocursor disable the cursor\n");
ErrorF("-core generate core dump on fatal error\n");
+ErrorF("-displayfd fd file descriptor to write display number to
when ready to connect\n");
ErrorF("-dpi int screen resolution in dots per inch\n");
#ifdef DPMSExtension
ErrorF("-dpms disables VESA DPMS monitor control\n");
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: Add -displayfd into -help text
Shall I resend it? I think I have set git send-email up correctly now.
On Tue, Apr 22, 2014 at 5:17 PM, Keith Packard wrote:
> Robert Ancell writes:
>
>> ErrorF("-cc intdefault color visual class\n");
>> ErrorF("-nocursor disable the cursor\n");
>> ErrorF("-core generate core dump on fatal error\n");
>> +ErrorF("-displayfd fd file descriptor to write display
>> number to when ready to connect\n");
>
> You'll need to fix your email program to not mangle patches...
>
> --
> keith.pack...@intel.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] os: Add -displayfd into -help text
Add -displayfd into -help text. It was mentioned in the man page but
seem to have been missed from the -help text.
---
os/utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/os/utils.c b/os/utils.c
index 60e828e..1555dbd 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -501,6 +501,7 @@ UseMsg(void)
ErrorF("-cc intdefault color visual class\n");
ErrorF("-nocursor disable the cursor\n");
ErrorF("-core generate core dump on fatal error\n");
+ErrorF("-displayfd fd file descriptor to write display
number to when ready to connect\n");
ErrorF("-dpi int screen resolution in dots per inch\n");
#ifdef DPMSExtension
ErrorF("-dpms disables VESA DPMS monitor control\n");
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: LightDM
On 16 August 2010 18:15, Matthieu Herrb wrote: > Could change the license in favor of the MIT license ? > There are serveral projects (including the BSDs) using X.Org that will > not accept GPLv3 code in their base system. I hadn't considered this, thanks. My preference is to use a copyleft license but I am open to considering license change if there is sufficient interest. Please reply here if you are an interested use-case! Note that the greeters can be under a different license to the daemon, so it could be an option to have a GTK/GNOME GUI under GPL and the daemon under MIT. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
LightDM
Hi, You may or may not be aware of my project to create a new display manager, LightDM [1]. The project is in an alpha state where I can run LightDM as my display manager, but it needs more work. A major goal of the project is to be cross-desktop and to reduce the divergence in display managers that has occurred post XDM. I'm interested in both technical feedback and how I can more closely align this project with freedesktop.org. Thanks, --Robert Ancell [1] https://launchpad.net/lightdm ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
