[PATCH] glamor: Use GL_STREAM_READ also for read/write access to a PBO

From: Michel Dänzer Otherwise the CPU may end up reading from non-cacheable memory, which is very slow. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84178 Signed-off-by: Michel Dänzer --- Keeping gl_usage in case we need to add back GLAMOR_ACCESS_WO. glamor/glamor_prepare.c | 5 +--

[PATCH] xinerama: Implement graphics exposures for window->pixmap copies

This code is using GetImage to accumulate a logical view of the window image (since the windows will be clipped to their containing screen), and then PutImage to load that back into the pixmap. What it wasn't doing was constructing a region for the obscured areas of the window and emitting graphic

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

Chris Wilson writes: > On Wed, Sep 24, 2014 at 01:23:26PM +0200, Egbert Eich wrote: > > Chris Wilson writes: > > > On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote: > > > > > > > > For panning one needs to be able to draw into the screen pixmap > > outside > > > > of the ar

Re: [PATCH] glamor: Fix leak of converted_bits in _glamor_upload_bits_to_pixmap_texture

Michel Dänzer writes: > From: Michel Dänzer > > ==9530== 808,575,600 bytes in 5,904 blocks are definitely lost in loss record > 4,602 of 4,602 > ==9530==at 0x4C28C20: malloc (vg_replace_malloc.c:296) > ==9530==by 0xAD29C98: _glamor_upload_bits_to_pixmap_texture > (glamor_pixmap.c:771)

Re: F21/F22: xorg-x11-drv: which for SiS?

Laércio de Sousa wrote on 2014-09-23 08:05 (GMT-0300): > 2014-09-23 3:37 GMT-03:00 Jasper St. Pierre composed: >> Felix Miata wrote: >>> xorg-x11-drv-sis seems to have disappeared. Did that happen on purpose? It >>> still exists as a selelection in Bugzilla. Xorg is looking for sis module >>> b

[PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues

By design, on 32-bit systems, the Xlib internal 32-bit request sequence numbers may wrap. There is some locations within xcb_io.c that are not wrap-safe though. The value of last_flushed relies on request to be sequential all the time. This is not given in the moment when the sequence has just wrap

[PULL] hw/xwin X11 <-> Windows clipboard integration refactoring

Hi Keith, This is a refactoring of the X11 <-> Windows clipboard integration code, which cleans up some cruft, makes it straightforward to build it correctly for 64-bit targets by undefining _XSERVER64, and perhaps paves the way to moving this code into a separate library. Please consider pulling

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

On Wed, Sep 24, 2014 at 01:23:26PM +0200, Egbert Eich wrote: > Chris Wilson writes: > > On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote: > > > > > > For panning one needs to be able to draw into the screen pixmap outside > > > of the area exposed by the crtc. > > > > Note that

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

On Wed, Sep 24, 2014 at 01:23:26PM +0200, Egbert Eich wrote: > Chris Wilson writes: > > On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote: > > > > > > For panning one needs to be able to draw into the screen pixmap outside > > > of the area exposed by the crtc. > > > > Note that

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

Chris Wilson writes: > On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote: > > > > For panning one needs to be able to draw into the screen pixmap outside > > of the area exposed by the crtc. > > Note that the screen pixmap still exists and is drawn into by the > clients. What sh

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

On Wed, Sep 24, 2014 at 12:34:29PM +0200, Egbert Eich wrote: > Here is the test scenario: > > Pineview Chipset, start a bare X server (without the other patch applied > to the driver), start xterm on it. > > On my system 'xrandr -q' gives: > > Screen 0: minimum 8 x 8, current 1366 x 768, maximum

Re: [PATCH driver/intel] Allow copy_front() to fail and clean up gracefully if it does

Chris Wilson writes: > On Wed, Sep 24, 2014 at 08:17:59AM +0200, Egbert Eich wrote: > > From: Egbert Eich > > > > copy_front() calls sna_pixmap_force_to_gpu() which may fail. If we pretend > > to have been successful and continue the caller sna_mode_resize() may > > finish > > successfull

vmmouse kernel driver

Hi! While looking at a vmmouse kernel driver, I wonder how the Xorg evdev driver can be configured to receive both absolute and relative events from the same device as the vmmouse sometimes sends absolute events and sometimes relative. Is the "IgnoreAbsoluteAxes" "False" option sufficient? Thanks

[PATCH] glamor: Fix leak of converted_bits in _glamor_upload_bits_to_pixmap_texture

From: Michel Dänzer ==9530== 808,575,600 bytes in 5,904 blocks are definitely lost in loss record 4,602 of 4,602 ==9530==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==9530==by 0xAD29C98: _glamor_upload_bits_to_pixmap_texture (glamor_pixmap.c:771) ==9530==by 0xAD2AE95: glamor_uplo

Re: [PATCH driver/intel] In sna_pixmap_alloc_gpu() process user selected tiling thru kgem_choose_tiling()

On Wed, Sep 24, 2014 at 08:18:32AM +0200, Egbert Eich wrote: > From: Egbert Eich > > In sna_pixmap_alloc_gpu() a different than the default tiling may be picked > by a usage hint. Before passing the tiling to kgem_create_2d() fix it up > by calling kgem_choose_tiling(). This avoids kgem_surface_s

Re: [PATCH] uxa/video: only call intel_xvmc_adaptor_init when xvmc is enabled

On Tue, Sep 23, 2014 at 08:13:11PM +0200, tobias.jako...@uni-bielefeld.de wrote: > Signed-off-by: Tobias Jakobi Thank you, I had stumbled across it but had forgotten to send the fix. Pushed, -Chris -- Chris Wilson, Intel Open Source Technology Centre