[ANNOUNCE] dri2proto 2.6
Chad Versace (1): Add attachment token DRI2BufferHiz Jesse Barnes (2): Revert dri2proto: make DRI2 swap event match GLX spec dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec git tag: dri2proto-2.6 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.bz2 MD5: 2eb74959684f47c862081099059a11ab dri2proto-2.6.tar.bz2 SHA1: ba65fc53376fd6e6b41bf6ef1e2ea1ba4b12ca96 dri2proto-2.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.gz MD5: 873142af5db695537cfe05e01d13541f dri2proto-2.6.tar.gz SHA1: ebce24ebc3c9674d40a9b100a4520e735670a23c dri2proto-2.6.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] glproto 1.4.14
Jesse Barnes (2): Revert glxproto: make GLX swap event struct match spec glproto: add a new GLXBufferSwapComplete struct that matches the spec git tag: glproto-1.4.14 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.14.tar.bz2 MD5: f48257daf0017f7a7667e5bf48ca3578 glproto-1.4.14.tar.bz2 SHA1: ab1941ad184a76c023858dd1623edd625d70fc2c glproto-1.4.14.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.14.tar.gz MD5: a8e4ca93ff07494eda6fdc6a273e8967 glproto-1.4.14.tar.gz SHA1: a5c22d0ccd1da979995a8ea480312b29df196121 glproto-1.4.14.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] dri2proto 2.6
Chad Versace (1): Add attachment token DRI2BufferHiz Jesse Barnes (2): Revert dri2proto: make DRI2 swap event match GLX spec dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec git tag: dri2proto-2.6 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.bz2 MD5: 2eb74959684f47c862081099059a11ab dri2proto-2.6.tar.bz2 SHA1: ba65fc53376fd6e6b41bf6ef1e2ea1ba4b12ca96 dri2proto-2.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.6.tar.gz MD5: 873142af5db695537cfe05e01d13541f dri2proto-2.6.tar.gz SHA1: ebce24ebc3c9674d40a9b100a4520e735670a23c dri2proto-2.6.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] glproto 1.4.14
Jesse Barnes (2): Revert glxproto: make GLX swap event struct match spec glproto: add a new GLXBufferSwapComplete struct that matches the spec git tag: glproto-1.4.14 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.14.tar.bz2 MD5: f48257daf0017f7a7667e5bf48ca3578 glproto-1.4.14.tar.bz2 SHA1: ab1941ad184a76c023858dd1623edd625d70fc2c glproto-1.4.14.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.14.tar.gz MD5: a8e4ca93ff07494eda6fdc6a273e8967 glproto-1.4.14.tar.gz SHA1: a5c22d0ccd1da979995a8ea480312b29df196121 glproto-1.4.14.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] dri2proto 2.4
On Wed, 4 May 2011 14:17:29 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: Gaetan Nadon (3): config: install and distribute dri2proto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 Jesse Barnes (1): dri2proto: make DRI2 swap event match GLX spec Marcin Kościelnicki (1): Fix DRI2Connect line encoding to match existing code Mike Stroyan (2): Add more info about dri2proto events Fix typo and obsolete reference in dri2proto.txt Ignore this release too; compatibility is more important than forcing bug fixes down people's throats. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] glproto 1.4.13
On Wed, 4 May 2011 14:16:50 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: Dave Airlie (2): glxtokens.h: add GLX_EXT_framebuffer_sRGB support. glproto: add GLX_ARB_context_create + GLX_ARB_context_create_profile Jesse Barnes (1): glxproto: make GLX swap event struct match spec git tag: glproto-1.4.13 Ok ignore this one, I should have made it backward compatible. The bug fix isn't important enough to cause existing builds to break. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] dri2proto 2.4
Gaetan Nadon (3): config: install and distribute dri2proto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 Jesse Barnes (1): dri2proto: make DRI2 swap event match GLX spec Marcin Kościelnicki (1): Fix DRI2Connect line encoding to match existing code Mike Stroyan (2): Add more info about dri2proto events Fix typo and obsolete reference in dri2proto.txt git tag: dri2proto-2.4 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.4.tar.bz2 MD5: 0cdeb1e95901813385dc9576be272bd3 dri2proto-2.4.tar.bz2 SHA1: 0650ad4bad3aabb58fda22ff3dbb4bc79d59bf7c dri2proto-2.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.4.tar.gz MD5: 0d70217f84d5059a8fe0d49a774252f8 dri2proto-2.4.tar.gz SHA1: d586e32f1344189964f13cca0d6599b16204b8c6 dri2proto-2.4.tar.gz Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] dri2proto 2.4
On Wed, 4 May 2011 14:17:29 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: Gaetan Nadon (3): config: install and distribute dri2proto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 Jesse Barnes (1): dri2proto: make DRI2 swap event match GLX spec Marcin Kościelnicki (1): Fix DRI2Connect line encoding to match existing code Mike Stroyan (2): Add more info about dri2proto events Fix typo and obsolete reference in dri2proto.txt Ignore this release too; compatibility is more important than forcing bug fixes down people's throats. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] glproto 1.4.13
On Wed, 4 May 2011 14:16:50 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: Dave Airlie (2): glxtokens.h: add GLX_EXT_framebuffer_sRGB support. glproto: add GLX_ARB_context_create + GLX_ARB_context_create_profile Jesse Barnes (1): glxproto: make GLX swap event struct match spec git tag: glproto-1.4.13 Ok ignore this one, I should have made it backward compatible. The bug fix isn't important enough to cause existing builds to break. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] glproto 1.4.13
Dave Airlie (2): glxtokens.h: add GLX_EXT_framebuffer_sRGB support. glproto: add GLX_ARB_context_create + GLX_ARB_context_create_profile Jesse Barnes (1): glxproto: make GLX swap event struct match spec git tag: glproto-1.4.13 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.13.tar.bz2 MD5: 9542f2d36751a8ad7eae9d8e176f70d4 glproto-1.4.13.tar.bz2 SHA1: 40c4e235a0a1ddff0ee508dcddc21cf9928c glproto-1.4.13.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.13.tar.gz MD5: 813a82dabd4f10d413d4b62261f293d6 glproto-1.4.13.tar.gz SHA1: 230a1cb03e543450996ab7b5e5cef27709e80105 glproto-1.4.13.tar.gz Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] Update DRI2 requests and replies for version 1.3.
On Wed, 27 Apr 2011 18:14:03 +0200 Julien Cristau jcris...@debian.org wrote: On Wed, Apr 27, 2011 at 09:02:10 -0700, Eric Anholt wrote: Here's the actual patch I meant to send. What should we do about SwapComplete? IIRC when this was shortly discussed on IRC (in November) the suggestion was to bump the DRI2 version to 2.0 and use generic events, which allow arbitrary length and don't have the only 64 extension events overall issue. Yeah, it's two bytes too long; I guess people aren't using the swap count field since it would be missing some low bits? Kristian suggested a new event, I guess that's the only choice we have for clients to get the low bits... -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Xcb] [PATCH] Update DRI2 requests and replies for version 1.3.
On Thu, 28 Apr 2011 18:04:58 +0200 Julien Cristau jcris...@debian.org wrote: On Wed, Apr 27, 2011 at 09:02:10 -0700, Eric Anholt wrote: Here's the actual patch I meant to send. What should we do about SwapComplete? I guess for the current (1.3) protocol version, not pretending that SwapComplete has a sbc_lo field is the easiest, since the server will never send it anyway. Yeah, the server will drop part of it; we can just truncate those fields from 8 to 6 bits and make them padding instead. We'll need a new event to send all the bits. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V)
On Sat, 28 Aug 2010 19:38:45 +0200
Krzysztof Halasa k...@pm.waw.pl wrote:
Hi,
It seems linux commit 0cc4d4300c broke i915 interlaced mode support
while fixing another issue (broken by my patch supporting interlaced
mode). Yep, I agree resetting the mode isn't the best idea (though it's
what several drivers do) and should not be needed in the first place.
I wonder if this is all working around a completely unneeded feature.
The core modesetting Linux code does the following:
drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V)
What is it good for, there in the core code?
The (any) driver (or output) either supports interlaced mode, which
forces it to revert this core operation with
drm_mode_set_crtcinfo(adjusted_mode, 0) (which my i915 patch did and
which may and do break special customizations), or it doesn't support
interlaced mode and then this flag isn't used at all.
Does the following patch (+ probably removing then unneeded calls in
e.g. radeon driver) fixes all these problems for good?
At least makes my i915 working again in interlaced mode. I could also
test on radeon, though I don't think this change could break it.
BTW interlaced mode on i915 requires X.org patch as well, see
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg11512.html
(only the userland driver patch and the kernel fix (below) is needed,
the main kernel part is already in place).
Perhaps someone in charge could apply the userland patch as well?
This is needed mainly for AV applications (e.g. connecting TV-alike
displays).
Obviously I'm open for suggestions, I'm not an X.org nor drivers/gpu
expert.
BTW2 is there some doc, note explaining all those adjusted_mode
magics? Why can't individual drivers mess with such things internally
when they need so?
BTW3 :-) I think the drm_mode_set_crtcinfo(x, CRTC_INTERLACE_HALVE_V)
logic has another flaw:
if (p-flags DRM_MODE_FLAG_INTERLACE) {
if (adjust_flags CRTC_INTERLACE_HALVE_V) {
p-crtc_vdisplay /= 2;
p-crtc_vsync_start /= 2;
p-crtc_vsync_end /= 2;
p-crtc_vtotal /= 2;
}
p-crtc_vtotal |= 1;
}
The last line should only be applied when we don't do
CRTC_INTERLACE_HALVE_V (i.e. the total number of lines in interlaced
mode has to be odd (X lines for odd field + X lines for even field + two
half-lines) - and only when we don't count these half-lines as full ones
(and we do, most of the time). If we do CRTC_INTERLACE_HALVE_V, we got
something like 288 or 240 field lines (instead of 576 or 480 for full
frame) and forcing the odd value makes no sense.
I'm not fixing this bug since I think we should remove this
CRTC_INTERLACE_HALVE_V completely (but I'll wait for comments to the
patch below first).
Thanks.
Signed-off-by: Krzysztof Hałasa k...@pm.waw.pl
I think this is ok; I didn't reply earlier because I didn't have the
sources handy to do a full review. IIRC there were lots of good
cleanups that could be done to our mode handling code, so the only
issue I have with this one is that it may not go far enough in fixing
up these functions to make them easier to read/use.
Maybe Dave can provide suggestions along those lines.
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: i915: video questions.
On Sat, 24 Jul 2010 14:04:55 +0200 Krzysztof Halasa k...@pm.waw.pl wrote: Hi, I wonder how should I do the video sync on i915+ hw properly. Should I expect Xvideo (with XV_SYNC_TO_VBLANK activated) to actually sync to the vertical refresh (i.e., Xvideo wouldn't be playing more frames than Vsync), or should it only eliminate the tearing problems (screen data not altered when displayed)? Video is usually encoded at a frame rate less than the refresh rate, so avoiding tearing is the most important part. For now, XV_SYNC_TO_VBLANK means the processing is halted with MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW. This IMHO means multiple frames can be processed (= displayed) as long as the CRTC is scanning outside the video window region. It doesn't mean there will be exactly a single video frame displayed for a single CRTC output frame. This is great for e.g. games, but not exactly for video. Should it stay this way? Correct, many frames could be generated and displayed but never shown due to the way we wait for the scanline window. Also, there is this DRM_IOCTL_WAIT_VBLANK which can be used to wait for actual Vsync IRQ. Should I use this for doing Xvideo - refresh sync? The problem is this approach requires messing with /dev/dri*, perhaps a Xvideo-only solution is better? DRM_IOCTL_WAIT_VBLANK can be used with GLX applications, though. That will only help you throttle your drawing, it won't guarantee you'll avoid tearing, especially on LCDs where the blank time can be very short. Perhaps we should create a different Xvideo attribute for the actual tearing avoidance (or just forget the attribute and always avoid the tearing with MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW)? Then the XV_SYNC_TO_VBLANK could be used for syncing (using IRQ?) with the actual vblank. Opinions? I think XV_SYNC_TO_VBLANK is intended for that. If you need something else (like throttling to refresh) as well, we should add a new attribute for that. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libdrm 2.4.20
New version includes a few fixes relative to 2.4.19.
Ben Skeggs (4):
nouveau: remove unused field from nouveau_bo
nouveau: fix segfault in nouveau_bo_new_tile() failure path
nouveau: fix annoying compiler warning
Fix pkgconfig includes for /usr/include/drm
Chris Wilson (2):
intel: Propagate some more error returns
intel: Repeat execbuffer if interrupted by signal
Eric Anholt (3):
intel: Only align Y-tiling pitch to the Y tile width.
intel: Align untiled buffer pitch to 64B.
intel: Install the header file in the libdrm/ directory.
Francisco Jerez (4):
nouveau: Update nouveau_class.h.
nouveau: Small lighting related addition to nouveau_class.h.
nouveau: Fix up the stride of NV20TCL_LIGHT_BACK_*.
nouveau: Regenerate nouveau_class.h.
Jerome Glisse (1):
drm/radeon: tab/whitespace cleanup
Jesse Barnes (2):
modetest: add optional select codepath
libdrm: bump version number to 2.4.20 for release
Julien Cristau (3):
libdrm_intel.pc: don't include ${includedir}/drm
libdrm_nouveau requires libdrm
Install headers to $(includedir)/libdrm
Pauli Nieminen (4):
libdrm: Move intel_atomic.h to libdrm core for sharing.
libdrm_radeon: Optimize cs_gem_reloc to do less looping.
libdrm: Fix error message if libdrm_intel|radeon is disabled and there is
no atomic ops.
Check HAVE_RADEON only after checking for atomic operations.
git tag: 2.4.20
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.bz2
MD5: 3c56e03172b236e14905ef9a68ba2f97 libdrm-2.4.20.tar.bz2
SHA1: f1448ac0f1c7a5f74a86d2fb50941fc12dc932db libdrm-2.4.20.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.gz
MD5: dcbf9aa0497c84c7e4af15adb0021955 libdrm-2.4.20.tar.gz
SHA1: e492e292df048566f910244bf5e0a9a8f07039b6 libdrm-2.4.20.tar.gz
___
xorg-announce mailing list
xorg-announce@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] dri2proto 2.2
New DRI2 proto release with the new driver type and swap etc. events. Aaron Plattner (1): Add a DRI2DriverVDPAU driver type. Gaetan Nadon (7): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jesse Barnes (9): Add SwapBuffers request Update protocol description for swapbuffers Add swap interval and synchronization support Fix DRI2SwapBuffers reply length Bump package version to 2.2 Add DRI2SwapInterval protocol Pad out DRI2 swap buffers reply Add DRI2 event support for DRI2BufferSwapComplete Fix cut paste error: Extension Requests - Extension Events Kristian Høgsberg (1): Make swapbuffers an async request git tag: dri2proto-2.2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.2.tar.bz2 MD5: 3ca8ddb42cd4ee31b8690031303221af dri2proto-2.2.tar.bz2 SHA1: 21e9c0c7e0be5fe971f51589d0573b0273202b7f dri2proto-2.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.2.tar.gz MD5: df58be4c4485d553337c0cb223a599fc dri2proto-2.2.tar.gz SHA1: 77f5afe65c63c3a9317de743a84d2c1e12fa72bd dri2proto-2.2.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] glproto 1.4.11
New GL proto with event support. Gaetan Nadon (7): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jesse Barnes (2): Add GLX swap buffers event support Bump version for release git tag: glproto-1.4.11 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.11.tar.bz2 MD5: 78e7c4dc7dcb74b1869fee7897e00f59 glproto-1.4.11.tar.bz2 SHA1: 7c2a723d488dc0e09e7e0e28bde838502d774b16 glproto-1.4.11.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.11.tar.gz MD5: 0753d5ebe5a1b7eae389eb480f8a2df7 glproto-1.4.11.tar.gz SHA1: e643f341d7bcdec529bbdbfaaf68b65ef296fdea glproto-1.4.11.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] dri2proto 2.2
New DRI2 proto release with the new driver type and swap etc. events. Aaron Plattner (1): Add a DRI2DriverVDPAU driver type. Gaetan Nadon (7): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jesse Barnes (9): Add SwapBuffers request Update protocol description for swapbuffers Add swap interval and synchronization support Fix DRI2SwapBuffers reply length Bump package version to 2.2 Add DRI2SwapInterval protocol Pad out DRI2 swap buffers reply Add DRI2 event support for DRI2BufferSwapComplete Fix cut paste error: Extension Requests - Extension Events Kristian Høgsberg (1): Make swapbuffers an async request git tag: dri2proto-2.2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.2.tar.bz2 MD5: 3ca8ddb42cd4ee31b8690031303221af dri2proto-2.2.tar.bz2 SHA1: 21e9c0c7e0be5fe971f51589d0573b0273202b7f dri2proto-2.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/dri2proto-2.2.tar.gz MD5: df58be4c4485d553337c0cb223a599fc dri2proto-2.2.tar.gz SHA1: 77f5afe65c63c3a9317de743a84d2c1e12fa72bd dri2proto-2.2.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] glproto 1.4.11
New GL proto with event support. Gaetan Nadon (7): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Jesse Barnes (2): Add GLX swap buffers event support Bump version for release git tag: glproto-1.4.11 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.11.tar.bz2 MD5: 78e7c4dc7dcb74b1869fee7897e00f59 glproto-1.4.11.tar.bz2 SHA1: 7c2a723d488dc0e09e7e0e28bde838502d774b16 glproto-1.4.11.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/glproto-1.4.11.tar.gz MD5: 0753d5ebe5a1b7eae389eb480f8a2df7 glproto-1.4.11.tar.gz SHA1: e643f341d7bcdec529bbdbfaaf68b65ef296fdea glproto-1.4.11.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem: Wait for VSync on pipe A and Wake up on pipe B
On Thu, 20 Aug 2009 09:41:28 + (GMT) Nicolas Cadio nicolas.ca...@ymail.com wrote: Hello, I have an application which must to synchronize with the vertical synchronisation of my display. To do this synchronization, I use a function of GLX (glXWaitVideoSyncSGI). This function call the function DRM to wait the vertical synchronization (drmWaitVBlank) and the driver (drm.ko) does a wait on the pipe A of my Xserver. But my output (LVDS) of my Xserver is connected to the pipe B and so the driver (drm.ko) does a wake up on the pipe B. So my applicaton is not synchronized with my display. I would like to know how to configure my application for it uses the pipe B when it does a wait for the vertical synchronization. Where I can configure my application for it uses the pipe B for the VSync ? Is it in the xorg.conf or elsewhere? With DRI2 we don't currently have a way to do this, but we're working on adding one (along with some other sync -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: man/intel.man src/i830_driver.c src/i830.h
On Mon, 29 Jun 2009 16:16:54 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
On 2009.06.24 09:26:27 -0700, Jesse Barnes wrote:
On Wed, 24 Jun 2009 10:37:34 +0200
Michel Dänzer mic...@daenzer.net wrote:
On Wed, 2009-06-24 at 10:33 +0200, Michel Dänzer wrote:
On Tue, 2009-06-23 at 15:06 -0700, Jesse Barnes wrote:
@@ -2663,10 +2665,23 @@ I830ScreenInit(int scrnIndex,
ScreenPtr pScreen, int argc, char **argv)
pI830-fb_compression = FALSE; }
+ /* SwapBuffers delays to avoid tearing */
+ pI830-swapbuffers_wait = TRUE;
+
+ /* Allow user override if they set a value */
+ if (xf86IsOptionSet(pI830-Options,
OPTION_SWAPBUFFERS_WAIT)) {
+ if (xf86ReturnOptValBool(pI830-Options,
OPTION_SWAPBUFFERS_WAIT, FALSE))
+pI830-swapbuffers_wait = TRUE;
+ else
+pI830-swapbuffers_wait = FALSE;
+ }
FYI, the xf86IsOptionSet() call is superfluous.
xf86ReturnOptValBool() returns its last argument (the default
value) if the option isn't set in the config file. So you could
simplify the code added above to
/* SwapBuffers delays to avoid tearing */
pI830-swapbuffers_wait =
xf86ReturnOptValBool(pI830-Options, OPTION_SWAPBUFFERS_WAIT,
FALSE);
Actually the default value should be TRUE of course - the default
values in your code are mixed, and I just copied pasted the
xf86ReturnOptValBool call.
And I was just copy pasting from some of our other option checking
code... looks like more of it could be simplified.
Jesse, but I can't find driver usage for this option in
1eec83a203c48822400742a1fb184b2cb52c62f7, or do I miss anything?
Arg you're right, I missed the i830_dri.c portion... Fixing now.
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: man/intel.man src/i830_driver.c src/i830.h
On Wed, 24 Jun 2009 10:37:34 +0200
Michel Dänzer mic...@daenzer.net wrote:
On Wed, 2009-06-24 at 10:33 +0200, Michel Dänzer wrote:
On Tue, 2009-06-23 at 15:06 -0700, Jesse Barnes wrote:
@@ -2663,10 +2665,23 @@ I830ScreenInit(int scrnIndex, ScreenPtr
pScreen, int argc, char **argv) pI830-fb_compression = FALSE;
}
+ /* SwapBuffers delays to avoid tearing */
+ pI830-swapbuffers_wait = TRUE;
+
+ /* Allow user override if they set a value */
+ if (xf86IsOptionSet(pI830-Options, OPTION_SWAPBUFFERS_WAIT))
{
+ if (xf86ReturnOptValBool(pI830-Options,
OPTION_SWAPBUFFERS_WAIT, FALSE))
+pI830-swapbuffers_wait = TRUE;
+ else
+pI830-swapbuffers_wait = FALSE;
+ }
FYI, the xf86IsOptionSet() call is superfluous.
xf86ReturnOptValBool() returns its last argument (the default
value) if the option isn't set in the config file. So you could
simplify the code added above to
/* SwapBuffers delays to avoid tearing */
pI830-swapbuffers_wait = xf86ReturnOptValBool(pI830-Options,
OPTION_SWAPBUFFERS_WAIT, FALSE);
Actually the default value should be TRUE of course - the default
values in your code are mixed, and I just copied pasted the
xf86ReturnOptValBool call.
And I was just copy pasting from some of our other option checking
code... looks like more of it could be simplified.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
On Tue, 28 Apr 2009 06:37:10 +0100 Alex Bennee kernel-hac...@bennee.com wrote: 2009/4/27 Florian Mickler flor...@mickler.org: On Sun, 19 Apr 2009 07:27:35 +0100 Alex Bennee kernel-hac...@bennee.com wrote: Heading the warnings in the menuconfig I did try and ensure I have all the up to date parts of user-space. With KMS enabled GDM starts up but then corrupts the display with vertical lines. Disabling the kernel config and everything starts up fine, UXA acceleration seems OK and the speed of compiz is finally back up to ~60fps thanks to the A17 fix. Am I missing another bit of user space for KMS to work properly? Apparently I was missing a key bit and had to enable fbdev from the command line: kernel /kernel-2.6-drm root=/dev/sda2 video=intelfb:mode=1440x900...@75,accel,hwcursor However I still saw the same corruption kick in when GDM started. I couldn't switch mode either which kinda defeated the point. The above seems to indicate that you have some FB drivers built into your kernel; that will likely fail in weird ways. Try disabling all the FB drivers, but keep CONFIG_FRAMEBUFFER_CONSOLE enabled. Then when you load the i915 driver you should get a nice console. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xserver: don't call prepare functions if set_mode_major is present
On Thu, 16 Apr 2009 11:13:46 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: KMS drivers use the set_mode_major function and shouldn't need any prepare functions called, so check for that in xf86SetDesiredModes to avoid any ugly flicker at EnterVT time. Any thoughts on this? Anyone have comments? Seems like this should be safe given what drivers need to do in set_mode_major but I may be overlooking some randr interaction... -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xserver: don't call prepare functions if set_mode_major is present
KMS drivers use the set_mode_major function and shouldn't need any
prepare functions called, so check for that in xf86SetDesiredModes to
avoid any ugly flicker at EnterVT time.
Any thoughts on this?
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index c6eed33..1b241cd 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -2549,18 +2549,23 @@ Bool
xf86SetDesiredModes (ScrnInfoPtr scrn)
{
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
+xf86CrtcPtr crtc = config-crtc[0];
intc;
-xf86PrepareOutputs(scrn);
-xf86PrepareCrtcs(scrn);
+/* A driver with this hook will take care of this */
+if (!crtc-funcs-set_mode_major) {
+ xf86PrepareOutputs(scrn);
+ xf86PrepareCrtcs(scrn);
+}
for (c = 0; c config-num_crtc; c++)
{
- xf86CrtcPtr crtc = config-crtc[c];
xf86OutputPtr output = NULL;
int o;
RRTransformPtr transform;
+ crtc = config-crtc[c];
+
/* Skip disabled CRTCs */
if (!crtc-enabled)
continue;
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Screen Corruption On Intel GM45
On Thu, 16 Apr 2009 23:04:36 +0100 Mike Lothian m...@fireburn.co.uk wrote: Hi I've noticed some horrible screen corruption using the lastest git xorg intel stack with in X. I've made the screen usable by booting with i915.modeset=0 with Linus's latest tree (this just gives me a back screen with the intel-next tree) I think the problem surfaced the same time as the tiling patches appeared - is there a way to disable tiling to test this? My 2.6.29 and last weeks git kernels would refuse to startx for very long not allowing kde to start (it was possible to recognise the loading screen) it would just crash X then try and start it again The latest intel-next tree allows KDE to start WITH the corruption now when KMS is enabled. When I VT switch the consoles look fine, it's only X that's corrupted Hope this isn't too random a bug report On GM45 you'll need http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=f544847fbaf099278343f875987a983f2b913134 which is currently in Eric's drm-intel-next branch. Otherwise in a KMS config the 2D driver will try to use a tiled buffer but the kernel won't set it up properly and you'll just get corruption. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Wed, 01 Apr 2009 17:46:08 +0200 Michel Dänzer mic...@daenzer.net wrote: The real problem was pointed out by Pierre Willenbrock: If glxPriv-pDraw is a pixmap, DrawableGone() destroys it, then later DRI2DestroyDrawable dereferences it... The patch below seems to work here - at least it hasn't crashed in a couple of hours, not sure about the leak yet. Note that unless I'm missing something, it might still be possible for this to occur with windows if the underlying DrawableRec is freed before this code is reached. Also, I don't really understand the logic behind clearing glxPriv-pDraw and -drawId here. In particular, I'm not sure DrawableGone will ever be called with glxPriv-refCount 1. If it won't, this change makes the assignments unreachable. And if it will, we'll again leak because the cleanup code won't be able to get to the underlying DrawableRec? So are you happy enough with this fix to push it, Michel? Memory usage is still high on Intel after the fix, but that may be due to bo caching, and this is an important fix... Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Sat, 28 Mar 2009 11:35:20 +0100 Adam Lantos h...@playma.org wrote: Jesse, Thanks for the patch, I'm testing it now - it looks promising :) X memory usage is more stable, but lsof | grep drm mm | wc -l still increases - after 10 minutes it went up from 100 to 500... Is this normal? Yeah that's probably due to our bo cache. We could probably make it smarter, but right now it'll continue to grow (theoretically more and more slowly over time). -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.
The loop seems broken to me. It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that. This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).
Any thoughts? I'd appreciate some more testers too... I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context. The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers). We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.
Yeah it does violate the layering... but the uref-drawablegone-unref
is a bit convoluted too.
The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak. You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed. I suggest this change to
DrawableGone in irc:
refcount = glxPriv-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Did you try that?
Ah no I think I had either = 1 or == 1 which clearly wouldn't work
since the glxPriv would be gone in the == 1 case. I'll try the 1 test.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.
The loop seems broken to me. It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that. This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).
Any thoughts? I'd appreciate some more testers too... I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context. The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers). We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.
The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak. You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed. I suggest this change to
DrawableGone in irc:
refcount = glxPriv-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..fec45b7 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -119,6 +119,7 @@ static int ContextGone(__GLXcontext* cx, XID id)
static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
{
ScreenPtr pScreen = glxPriv-pDraw-pScreen;
+int refcount;
switch (glxPriv-type) {
case GLX_DRAWABLE_PIXMAP:
@@ -127,9 +128,12 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
break;
}
-glxPriv-pDraw = NULL;
-glxPriv-drawId = 0;
+refcount = glxPriv-refCount;
__glXUnrefDrawable(glxPriv);
+if (refcount 1) {
+ glxPriv-pDraw = NULL;
+ glxPriv-drawId = 0;
+}
return True;
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Thu, 26 Mar 2009 22:02:52 +0200 Vasily Khoruzhick anars...@gmail.com wrote: On Wednesday 25 March 2009 19:21:51 Jesse Barnes wrote: Has anyone else seen this leak? Anyone care to educate me a bit more about GLX drawable lifetime rules? Yep, my system suffer from this leak too. Yeah sounds pretty widespread; it'll only get worse as the radeon DRI2 bits become more common. diff --git a/glx/glxext.c b/glx/glxext.c index c882372..73e5a9b 100644 --- a/glx/glxext.c +++ b/glx/glxext.c @@ -127,9 +127,9 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid) break; } -glxPriv-pDraw = NULL; glxPriv-drawId = 0; __glXUnrefDrawable(glxPriv); Maybe, we should somehow check if glxPriv is still valid after Unref before assigning something to the pDraw? (I'm not sure, I'm not familiar with X internals) Yeah, I'm just learning this stuff too... Now that I've walked through the life of a GLX pixmap a bit things look even more convoluted. GLX pixmaps are created by __glXDRIscreenCreateDrawable at various times, either explicitly by something like __glXGetDrawable or implicitly by a glXCreateWindow call. All of these end up in DRI2CreateDrawable which either bumps the refcount of an existing pixmap or creates a new one (though with no buffers attached). The drawables get destroyed by their own destroy hook, which points at __glXDRIdrawableDestroy (yes this and the one above should probably have been called glXDRI2...), which is either explicitly called by a cleanup routine (error handling in drawable creation for example), free context time, free screen time, or when a drawable is deref'd and the count drops to 0. What's weird is that __glXUnrefDrawable might be called by DrawableGone (the top level X managed resource for glx drawables) due to __glXUnrefDrawable calling FreeResourceByType, but then DrawableGone will again call __glXUnrefDrawable... I think krh noticed this today and suggested we check the refcount in DrawableGone... But it seems like since __glXUnrefDrawable only frees the resource if the refcount reaches 0, we shouldn't need another unref in DrawableGone... So maybe that's what my fix was running into. Anyway back to more testing reading. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Thu, 26 Mar 2009 14:20:07 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
What's weird is that __glXUnrefDrawable might be called by
DrawableGone (the top level X managed resource for glx drawables) due
to __glXUnrefDrawable calling FreeResourceByType, but then
DrawableGone will again call __glXUnrefDrawable... I think krh
noticed this today and suggested we check the refcount in
DrawableGone... But it seems like since __glXUnrefDrawable only frees
the resource if the refcount reaches 0, we shouldn't need another
unref in DrawableGone... So maybe that's what my fix was running
into.
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before the
call to Unref, so we never got into DRI2DestroyBuffers, thus the leak.
The loop seems broken to me. It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free, so
I've fixed up the code to conform to that. This means removing the GLX
priv frees from DRI and DRI2 routines and putting them here and using
the GLX unref routine everwhere (since it will only free the resource
when the refcount reaches 0).
Any thoughts? I'd appreciate some more testers too... I'm not quite
sure about the generic DoDestroyDrawable change, but if the refcount is
always 1 there anyway it shouldn't make a difference and seems more
correct.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index ab2d91b..08b866d 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -1222,7 +1222,7 @@ static int DoDestroyDrawable(__GLXclientState *cl, XID
glxdrawable, int type)
}
}
-FreeResource(glxdrawable, FALSE);
+__glXUnrefDrawable(pGlxDraw);
return Success;
}
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 223b06e..253d868 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -237,8 +237,6 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
serverClient, drawable-pDraw);
__glXleaveServer(GL_FALSE);
}
-
-xfree(private);
}
static GLboolean
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 4e76c71..4fdc7df 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -106,8 +106,6 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
* aready have taken care of this, so only call if pDraw isn't NULL. */
if (drawable-pDraw != NULL)
DRI2DestroyDrawable(drawable-pDraw);
-
-xfree(private);
}
static void
diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..0b6c752 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -120,6 +120,8 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
{
ScreenPtr pScreen = glxPriv-pDraw-pScreen;
+glxPriv-destroy(glxPriv);
+
switch (glxPriv-type) {
case GLX_DRAWABLE_PIXMAP:
case GLX_DRAWABLE_PBUFFER:
@@ -129,7 +131,7 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
-__glXUnrefDrawable(glxPriv);
+xfree(glxPriv);
return True;
}
diff --git a/glx/glxutil.c b/glx/glxutil.c
index bc71087..61323f5 100644
--- a/glx/glxutil.c
+++ b/glx/glxutil.c
@@ -52,11 +52,9 @@ void
__glXUnrefDrawable(__GLXdrawable *glxPriv)
{
glxPriv-refCount--;
-if (glxPriv-refCount == 0) {
+if (glxPriv-refCount == 0)
/* remove the drawable from the drawable list */
FreeResourceByType(glxPriv-drawId, __glXDrawableRes, FALSE);
- glxPriv-destroy(glxPriv);
-}
}
GLboolean
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[RFC] glx: fix DRI2 memory leak
In trying to track down the memory leak in 20704, I found that the DRI2 drawable destroy routine doesn't seem to get called when new drawables are created and old ones destroyed (as in the glViewport case in the bug). The GLX core code takes care of destroying drawables correctly though, and even calls DestroyPixmap at the right time. However, DRI2 drawables have more state associated with them than just a single pixmap, so we have a __glXDRIdrawableDestroy function that takes care of that. However, by the time we get there, the GLX drawable is gone, so I never saw the if (drawable-pDraw != NULL) DRI2DestroyDrawable(drawable-pDraw); case get triggered... The simple patch below fixed that, but apparently isn't correct (see the bug report) since it causes crashes after a time. My patch was missing another change to set the private-count correctly in dri2GetBuffers though, which may be part of the fix as well. Has anyone else seen this leak? Anyone care to educate me a bit more about GLX drawable lifetime rules? Thanks, Jesse diff --git a/glx/glxext.c b/glx/glxext.c index c882372..73e5a9b 100644 --- a/glx/glxext.c +++ b/glx/glxext.c @@ -127,9 +127,9 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid) break; } -glxPriv-pDraw = NULL; glxPriv-drawId = 0; __glXUnrefDrawable(glxPriv); +glxPriv-pDraw = NULL; return True; } ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with KMS on drm-intel-next branch
On Sunday, March 15, 2009 6:23:59 am Mike Lothian wrote: Hi I've been using KMS on Intel since it was merged with 2.6.29. In parallel to this I've also been testing the drm-intel-next branch of anholt's git tree This stopped working for me about 2 weeks ago. When the kernel normally switches to the correct resolution on mainline the drm-intel-next kernel turns the screen black then slowly gets brighter from the edges going through purple into white, showing all the imperfections in the screen I'm not sure what's happening in the background as my laptop never gets to the point where I can SSH in. It's a: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Hope this helps in some way If it used to work but now doesn't, you may be able to use git bisect to get down to the offending commit. Either way, please file a bug at bugs.freedesktop.org for this problem if one doesn't already exist. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with KMS on drm-intel-next branch
On Monday, March 16, 2009 4:25:52 pm Mike Lothian wrote: 2009/3/16 Jesse Barnes jbar...@virtuousgeek.org: On Sunday, March 15, 2009 6:23:59 am Mike Lothian wrote: Hi I've been using KMS on Intel since it was merged with 2.6.29. In parallel to this I've also been testing the drm-intel-next branch of anholt's git tree This stopped working for me about 2 weeks ago. When the kernel normally switches to the correct resolution on mainline the drm-intel-next kernel turns the screen black then slowly gets brighter from the edges going through purple into white, showing all the imperfections in the screen I'm not sure what's happening in the background as my laptop never gets to the point where I can SSH in. It's a: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Hope this helps in some way If it used to work but now doesn't, you may be able to use git bisect to get down to the offending commit. Either way, please file a bug at bugs.freedesktop.org for this problem if one doesn't already exist. Thanks, -- Jesse Barnes, Intel Open Source Technology Center Hi I've just finished bisecting and the dodgy commit was: drm/i915: Use LVDS config in Driver feature BDB for integrated LVDS check ed356c1946edc4017799de0371ef229bffa5e72c I hope this helps Yes it does, thanks. Zhenyu has been making changes in this area recently. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel memory leakage
On Friday, February 6, 2009 2:21 pm Marco wrote: Same for me, starting iceweasel on my GM45 bump suddenly out of swap. Bisected to: deneb:~/src/xf86-video-intel.git# git bisect view commit 8d4bc36fae50b09a73ba2cfab920adb32141a358 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Mon Jan 26 17:14:06 2009 -0800 Support tiled back/depth on 915-class hardware with DRI2. Set alignments, tile settings and flags correctly in the 2D driver to suppor tiled rendering. UXA's create pixmap function currently assumes the worst about the alignment constraints; that should probably be fixed. Some of the 1M alignment fixes could probably be done more cleanly as well. (END) In fact after reverting it, all seems fine. Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: Any 3D app is slow in resolution higher than 800x600 with UXA+DRI2
On Monday, January 26, 2009 1:34 pm Vasily Khoruzhick wrote: On 26 January 2009 22:02:30 Jesse Barnes wrote: On Sunday, January 25, 2009 12:33 pm Vasily Khoruzhick wrote: Hi, it seems I've found one more bug for gma950+uxa+dri2 configuration: Any 3D application is _really_ slow if it runs in window with size higher than 800x600. Steps to reproduce: 1. Use gma950 hardware with xf86-video-intel from git and mesa from git, xorg-server-1.5.99.901, libdrm from git, 2.6.28 kernel + 6 patches 2. Download and install secret maryo chronicles (or any game you like that uses 3D) 3. Disable fullscreen mode and set resolution to 800x600 - game should run smoothly 4. Disable fullscreen mode and set resolution to 1024x768 (or higher) - game should became unplayable. Same issue with compiz. The patchset I just posted to intel-gfx might help with this (http://lists.freedesktop.org/archives/intel-gfx/2009-January/001172.html ); it allows for tiled rendering on 9xx chips w/DRI2. On some machines it makes a 10x difference. Sorry, but on which kernel I should apply first patch? It doesn't apply on 2.6.28 + 6 patches (2008 q4 :)) The kernel patch was against drm-intel-next of last week. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: http://wiki.x.org/wiki/Development/git [was: Fedora 10: Trouble installing libdrm (2.4.4) for latest Intel driver (2.6)]
On Wednesday, January 21, 2009 7:38 pm Sergio Monteiro Basto wrote: Hi, Since I also works with Fedora 10, I am also interested in this thread :) On Wed, 2009-01-21 at 15:03 -0800, Dan Nicholson wrote: I've attached my log file. Am I supposed to have a rules file for evdev? Unfortunately, the script you followed doesn't seem to tell you about handling the XKB data. You can either install xkeyboard-config or follow the instructions for Making the keyboard work here: http://wiki.x.org/wiki/Development/git ok I found some updates on Development/git, and that a cool page , but I have some questions . On section: running new stack * rmmod i915 # assuming you're using Intel * rmmod drm * insmod path_to_drm_tree_above/linux-core/drm.ko * insmod path_to_drm_tree_above/linux-core/i915.ko This isn't more applicable on Intel isn't it ? but as example for others that don't use the new drm kernel are fine :) Right, please correct this on the wiki. :) For Intel, the Linux drivers are maintained in-tree. The BSD variants are generally ported from there (or the mailing list) into their respective trees nowadays. Other question is about section: Building DRM. On Intel (that is my development case ) make install (without make -C linux-core ) , will overwrite drm kernel headers , that is good ? make install from a kernel tree will overwrite the versions in /lib/modules, but it's easier to just copy them by hand from drivers/gpu/ to /lib/modules. To be honest I don't know if libdrm could be different of drm kernel and they could act independently or if we should check if headers of libdrm and headers of drm kernel are equal. Some clues about this question are welcome . Some distros are starting to use the kernel headers rather than the libdrm headers now. I think this makes sense long term; however since the headers are slightly out of sync it has caused build problems for some packages. Jesse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
On Friday, January 16, 2009 1:55 pm Rémi Cardona wrote: Le 16/01/2009 21:21, Jesse Barnes a écrit : On Monday, January 5, 2009 12:55 pm Tiago Vignatti wrote: Right now a thing that is annoying me is how others cursors, sw rendered, could be implemented. I want to avoid two differents sets of the same code in different contexts. IMHO conceptually all these cursor update things must be in-kernel. Painting a cursor image seems to be quite hard as we have to save/restore areas under the cursor. I remember that anholt had an idea concerning this, but I do not remember details. I really like the idea of having this in the kernel for latency reasons, but yeah we do need to solve the sw case as well as implementing some acceleration code. OTOH it might be reasonable to push the problem of multiple, large, and or funky format cursors out to userspace, since those are relatively uncommon (64x64 32 bit ARGB ought to be enough for everybody right? :). Not for firefox. Any dragdrop in gecko will result in huge ARGB cursors. Even just dragging and dropping a tab results in a cursor that's at least 150x20px. Gah, yeah forgot about drag drop of big icons... Maybe Kristian was right that all cursors should be done in software; hardware just doesn't provide the flexibility desktops want these days. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
On Monday, January 5, 2009 12:55 pm Tiago Vignatti wrote: Right now a thing that is annoying me is how others cursors, sw rendered, could be implemented. I want to avoid two differents sets of the same code in different contexts. IMHO conceptually all these cursor update things must be in-kernel. Painting a cursor image seems to be quite hard as we have to save/restore areas under the cursor. I remember that anholt had an idea concerning this, but I do not remember details. I really like the idea of having this in the kernel for latency reasons, but yeah we do need to solve the sw case as well as implementing some acceleration code. OTOH it might be reasonable to push the problem of multiple, large, and or funky format cursors out to userspace, since those are relatively uncommon (64x64 32 bit ARGB ought to be enough for everybody right? :). -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: KMS with Xorg on G45 failing
On Tuesday, January 6, 2009 5:41 pm Mike Lothian wrote: 2009/1/7 Mike Lothian m...@fireburn.co.uk: 2009/1/7 Jesse Barnes jbar...@virtuousgeek.org: On Tuesday, January 6, 2009 3:53 pm Mike Lothian wrote: 2009/1/6 Jesse Barnes jbar...@virtuousgeek.org: On Tuesday, January 6, 2009 2:35 pm Mike Lothian wrote: Hi there Thought I'd send in some info about Xorg with a KMS kernel, libdrm and xf86-video-intel I've attached my dmesg and Xorg.0.log The only outputs are LVDS 15 screen an a disconnected VGA out and HDMI connectors I'll quite happily submit a bug but thought the code was a little too new to harp on about especially if this is a known issue Let me know if I can help further Looks like the 3D driver init failed... Maybe you need to rebuild your DRI driver as well against the same libdrm? I rebuild libdrm mesa and xf86-video-intel each time is there something else I'm missing? This one looks like a Mesa mismatch somehow, so try rebuilding that too. -- Jesse Barnes, Intel Open Source Technology Center OK I've recompiled libdrm mesa and xf86-video-intel using their master tree's and recompiled the head drm-intel-next branch of the kernel the versions I were using before were only a few hours old Good news X starts, bad news is the screen goes black once KDE starts to load, pretty sure it's when the compositing is started Another strange things happened, normally with KMS all my VTs are at the laptops native resolution now they're in the top left corner at what looks like 800x600 but not streched Also when booting from a non-KMS but regular GEM kernel UXA doesn't work now. I've had to switch back to EXA I'm attaching my dmesg and Xorg log from the KMS retry Could any of the problems be caused by: [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 Cheers Mike Oh yes and when X started is went back to the native resolution The 800x600 but not stretched issue sounds like it could be related to the initial_config bug I fixed this week. Can you give Dave's latest drm-next tree a try? It fixes that bug (among others). Also the 2D driver needs a few fixes we're still working on. The intel-...@lists.freedesktop.org is a good place to watch for those. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: KMS with Xorg on G45 failing
On Tuesday, January 6, 2009 2:35 pm Mike Lothian wrote: Hi there Thought I'd send in some info about Xorg with a KMS kernel, libdrm and xf86-video-intel I've attached my dmesg and Xorg.0.log The only outputs are LVDS 15 screen an a disconnected VGA out and HDMI connectors I'll quite happily submit a bug but thought the code was a little too new to harp on about especially if this is a known issue Let me know if I can help further Looks like the 3D driver init failed... Maybe you need to rebuild your DRI driver as well against the same libdrm? -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: KMS with Xorg on G45 failing
On Tuesday, January 6, 2009 3:53 pm Mike Lothian wrote: 2009/1/6 Jesse Barnes jbar...@virtuousgeek.org: On Tuesday, January 6, 2009 2:35 pm Mike Lothian wrote: Hi there Thought I'd send in some info about Xorg with a KMS kernel, libdrm and xf86-video-intel I've attached my dmesg and Xorg.0.log The only outputs are LVDS 15 screen an a disconnected VGA out and HDMI connectors I'll quite happily submit a bug but thought the code was a little too new to harp on about especially if this is a known issue Let me know if I can help further Looks like the 3D driver init failed... Maybe you need to rebuild your DRI driver as well against the same libdrm? I rebuild libdrm mesa and xf86-video-intel each time is there something else I'm missing? This one looks like a Mesa mismatch somehow, so try rebuilding that too. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.4.3
Hopefully this is the last 2.4.x release. This one just includes a few changes relative to 2.4.2, but the G4x stolen memory bit is an important one. Adam Jackson (1): Quirk: No LVDS on Dell Studio Hybrid Carl Worth (1): Disable frame buffer compression by default for GM965. Eric Anholt (1): Fix broken stolen memory counting on G4X. Jesse Barnes (3): Don't allocate a pipe for hotplug detection Add a few programs to .gitignore Update version to 2.4.3 for release Zhenyu Wang (3): Disable render standby Add backlight kernel method support on Asus and Eeepc quirk LVDS on Asus Eee box git tag: xf86-video-intel-2.4.3 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.3.tar.bz2 MD5: a664819288b98a37f77ab6ae1e14c9d9 xf86-video-intel-2.4.3.tar.bz2 SHA1: 8335294c9b76b1f9daad5082d2290555ba2dbce5 xf86-video-intel-2.4.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.3.tar.gz MD5: cc38aa1c53bb49e4c4828968120df8eb xf86-video-intel-2.4.3.tar.gz SHA1: 42535298c358c20c0fd75214a043ca6cb5f1ccca xf86-video-intel-2.4.3.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.5.1
Quite a few fixes in this relative to 2.5.0, recommended for anyone currently using the 2.5.x series. Thanks, Jesse Adam Jackson (1): Quirk: No LVDS on Dell Studio Hybrid Carl Worth (1): Ignore intel_gtt binary Dave Airlie (1): Default kernel mode setting to off, add configure flag to enable Jesse Barnes (4): Don't modify render standby if kernel mode setting is active Make I830FALLBACK debugging a runtime instead of compile-time option. Update version to 2.5.1 in preparation for release Make sure DRM library paths are included Keith Packard (1): Use long crt hotplug activation time on GM45. Maxim Levitsky (1): Add an option to make the overlay be the first XV adaptor. Zhenyu Wang (12): Make IS_GM45 into IS_G4X define SDVO: fix wrong order of sdvo version's major/minor SDVO: add HDMI audio encrypt change bit for GetInterruptEventSource command SDVO: fix sdvo tv format and sdtv resolution request/reply definition SDVO: add GetScaledHDTVResolutionSupport command SDVO: add command for set monitor power state SDVO: fix more command definition errors TV: white space cleanup TV: fix default contrast and saturation modifier TV: save serveral TV_CTL register fields in mode set TV: fix timing parameters for PAL, 480p, 1080i quirk LVDS on Asus Eee box git tag: xf86-video-intel-2.5.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.5.1.tar.bz2 MD5: 62e96948860b7a8507963300f56d0d16 xf86-video-intel-2.5.1.tar.bz2 SHA1: 58f6f005a698e63cb34ba1b011b0ddce0b0b3862 xf86-video-intel-2.5.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.5.1.tar.gz MD5: 8cc92bc60a2366bbd018aa0c7230ab13 xf86-video-intel-2.5.1.tar.gz SHA1: 4a6cecbd7cd13d6f51b3d88933001bc77a966e2f xf86-video-intel-2.5.1.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.4.98
This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. Looks like we won't get *all* the blockers fixed, but I think we did pretty well. Changelog from 2.4.97 below. Thanks, Jesse Adam Jackson (1): Fix Mac mini crash in DDC mode probe Bryce Harrington (1): Add TV out quirk for HP Compaq nx6110 Carl Worth (8): Examine picture repeatType as well as repeat field. Add support for RepeatPad and RepeatReflect. Prefer repeatType field over using both repeat and repeatType. Fallback to software for RepeatNone with transformed RGB-only pictures. Revert Fallback to software for RepeatNone with transformed RGB-only pictures. Rename default_color to border_color Document and use 'legacy' border color mode Disable frame buffer compression by default for GM965. Daniel Stone (1): i830: Fix timer leak Dave Airlie (1): mode: fix missing comma David Schleef (1): Bug #17277: fix upscaling limit Eamon Walsh (2): Remove unused exa_pixmap_key. Change uxa private keys to integer variables. Eric Anholt (12): Add some MCHBAR registers for debugging tile swizzling issues. Bug #17446: Don't try to manage IRQs in GEM mode. Track move of bufmgr functions to libdrm_intel. Track the move of irq emit/wait to fake bufmgr. Track move of exec to bufmgr, and restoration of emit/wait funcs for non-drm. Work around libpciaccess reporting a 0 rom size by guessing. Add support for RepeatPad and RepeatReflect to 915 and 830-class Render accel. Fix bios_reader build against old servers. Fix driver build against server 1.4.2. Add a GTT dumper for G4x debugging. Fix broken stolen memory counting on G4X. Remove gratuitous flushing in EXA after solid operations. Fabio (1): Man page patch to clarify meaning of VideoRam option with i810/i815 Jesse Barnes (15): Update version to post-2.5 Fix UXA build for distcheck Fix build when using kernel DRM headers Only BO map render state if kernel mode setting is active Add Cappuccino SlimPRO SP625F to no LVDS quirks list Add no TV out quirk for HP Compaq nx6110 Revert Add no TV out quirk for HP Compaq nx6110 Update supported hardware list Work around gcc uninitialized variable warnings Use -Werror by default Use VBT LFP info pointers by default Be more verbose about panel data in VBIOS dumper Revert Use -Werror by default Document more VBIOS functionality Update version to 2.4.98 for 2.5.0 release candidate Julien Cristau (1): Typo fix Keith Packard (6): Use uintptr_t instead of uint64_t to hold pointer value Eliminate INT10 call to get BIOS contents i830 nondrm batch buffer insertion was missing ADVANCE_LP_RING() call For non-DRM, add NOOPs after BATCH_BUFFER_START to verify completion XAA tiling support was mis-computing adjusted pitch (4 instead of 2) Handle differently tiled front/back/depth/third in DRI window management Lukas Hejtmanek (1): Fix driver build against server master. Olivier Fourdan (1): Fix ordering of VGA vs. plane disable Robert Noland (2): Check for drm before calling modeset ioctl. Fix typo in last commit Shuang He (1): Fix a typo in G965 texture video code Stefan Dirsch (1): Pipe A force quirk for Toshiba Satellite A30. Xiang, Haihao (4): Put back check for pI830-hw_status in setting hws in non-GEM mode. Move bufmgr init earlier so it's available at I830DRIDoMappings time. Put back check for pI830-hw_status in setting hws in non-GEM mode. Move bufmgr init earlier so it's available at I830DRIDoMappings time. Zhenyu Wang (15): Destroy bufmgr after allocation finish Fix X exit crash in NoAccel Disable render standby Add support for G41 chipset Check display stride limit when allocate front buffer Fix output detection for DVI-I Bug #16515: Fix VT switch with DVI on G45 Do force CRT detect sequence twice on 4 series chipset Render register clock gating disable fix on 4 series chipset Bug #16631: add option for SDVO force detect Put forware VBIOS data parsing Remove Lenovo T61 TV quirk Bug #17892: Fix possible crash in CRT probe Make GTT dumper work on other 9XX chips Don't handle irq in GEM mode git tag: xf86-video-intel-2.4.98.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.98.0.tar.bz2 MD5: e3ab56e8d15205ab63978d0336fd385f xf86-video-intel-2.4.98.0.tar.bz2 SHA1: 8213fc95ceaa347cf96f70375d8820818b406400 xf86-video-intel-2.4.98.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.98.0.tar.gz MD5: 9ed649916cc1f1a57bcdde6619c294d6 xf86-video-intel-2.4.98.0
Re: [ANNOUNCE] xf86-video-intel 2.5.0
On Tuesday, October 21, 2008 9:33 am samuel wrote: I've tried this driver now. doesn't seem to work here... gives me a fatal error and leaves my consoles in a non usable state... any suggestions? gr,S. specs: mesa 7.2 xorg-server 1.5.2 libdrm 2.4.0 kernel 2.6.27 drm from git When you say drm from git do you mean the DRM modules? If so, you shouldn't be using those. If you want the latest DRM bits, run the drm-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git. That includes a full kernel containing all the latest fixes. Jesse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sunday, October 19, 2008 11:50 am Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. That should be defined in the libdrm headers. According to http://dri.freedesktop.org/libdrm/ there's a 2.4.0 release now, but I haven't seen the announcement yet... maybe Eric's mail didn't make it through? So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). Hm, that sounds bad... What kind of DRM errors are you seeing? If it's just these: [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 that should be ok. That's just the 2D driver checking for GEM (we should probably make the messages a little less threatening, but really they're normal for non-GEM configurations). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sunday, October 19, 2008 12:16 pm Eric Anholt wrote: On Sun, 2008-10-19 at 20:50 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. libdrm 2.4.0 is released. http://dri.freedesktop.org/libdrm/ I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. Yeah I guess it's not common to send out announcements about libdrm releases, but maybe we should start. Following the X.Org announcement template would be a good way to go I think, and would allow people to see what changes the release includes, etc. Anyway glad it's finally out; that means we can release 2.5.0. /me trolls the bug list to see if there are any last minute blockers. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.5.0
the sync active bits like we're supposed to, matching the BIOS. Get HDMI output working. Fix hdmi POSTING_READ to use the register number instead of the register value. Automatically detect the presence of HDMI. Fix a crash in i830_sdvo_init error paths by setting up dev_priv earlier. Set tiling state for buffers allocated using GEM. Fix DSPARB setting on 845/865, which have only the AEND field and 96 entries. Bump version number past the 2.4 stable branch. Get prototype for i830_bios_get_tv(). Fix uninitialized-use warning in i830_debug.c ring dumping. Fix distcheck. Don't set up the HWS page in GEM mode now that the kernel manages it. intel-gem: Give a better error message if the kernel rejects the tiling mode. intel-gem: Use new getparam to detect kernel GEM support. intel_idle: Instead if #if 0, add an ignore flag for unreliable INSTDONE bits. Set lvds_ddc_mode before use to avoid a segfault on mac mini. Add some MCHBAR registers for debugging tile swizzling issues. Bug #17446: Don't try to manage IRQs in GEM mode. Track move of bufmgr functions to libdrm_intel. Track the move of irq emit/wait to fake bufmgr. Track move of exec to bufmgr, and restoration of emit/wait funcs for non-drm. Work around libpciaccess reporting a 0 rom size by guessing. Add support for RepeatPad and RepeatReflect to 915 and 830-class Render accel. Fix bios_reader build against old servers. Fix driver build against server 1.4.2. Add a GTT dumper for G4x debugging. Fix broken stolen memory counting on G4X. Remove gratuitous flushing in EXA after solid operations. Enable Option Legacy3D for 965 as well, and clarify both the docs and code. Fabio (1): Man page patch to clarify meaning of VideoRam option with i810/i815 Hong Liu (1): Fix SDVO HDMI output. Jesse Barnes (60): Add support for keeping vblank counters sane across mode setting Fix back buffer damage handler for 965+ chips Remove ErrorF debugging from modeset ioctl Add pipe a force enable quirk for Lenovo T60 Add pipea force enable quirk for HP Pavilion ze4944ea Improve FBC size checking Improve VBIOS feature detection, add SSC support Add VBIOS based TV connector detection Don't disable pipe A on 855 chips Choose a split for DSPARB based on the configured modes for both planes. Add no LVDS quirk for Transtec Senyo 610 mini PC Update DSPARB while planes are still off Update man page Reorganize VBIOS code Revert Switch to using a buffer object for the vertex buffer Initial port of kernel modesetting from old intel-kernelmode branch Make it actually build the kernel stuff if possible Add EXA pixmap management functions for kernel mode setting Update DRM based modesetting support Don't wait for ring if kernel mode setting is active Don't run old accel init code Don't set tiling (yet) if kernel mode setting is active Map gen4 render state buffer before initializing Make EXA UXA share bo getting function Use pwrite for cursor updates Fixup AccelMethod kernel mode setting code Map/unmap render state only when bo is available Fix pipe A force quirk Remove last TTM bits Pack bdb_general_definitions block Remove unused VBIOS flag defines Add VBIOS software flags dumper program Add quirk for pre-915s with working PFIT regs Bail out if kernel mode setting is active but DRI fails Don't allocate EXA offscreen space if kernel mode setting is active Use GTT mapping for EXA PrepareAccess function Add swf_dumper to .gitignore Add more panel debugging info to register dump vbios reader Don't allocate a pipe for hotplug detection Don't disable planes in i830_update_dsparb Fix compiler warnings in VBIOS utils Hide kernel mode setting EXA code behind XF86DRM_MODE Update version to post-2.5 Update version to 2.4.97 for first 2.5 test release Fix UXA build for distcheck Fix UXA build for distcheck Fix build when using kernel DRM headers Only BO map render state if kernel mode setting is active Add Cappuccino SlimPRO SP625F to no LVDS quirks list Add no TV out quirk for HP Compaq nx6110 Revert Add no TV out quirk for HP Compaq nx6110 Update supported hardware list Work around gcc uninitialized variable warnings Use -Werror by default Use VBT LFP info pointers by default Be more verbose about panel data in VBIOS dumper Revert Use -Werror by default Document more VBIOS functionality Update version to 2.4.98 for 2.5.0 release candidate Bump version to 2.5.0 for release Julien Cristau (6): Fix gen4asm rule to work with a build dir Link the driver
Re: Intel card with uxa enabled causes garbled screen
On Monday, October 13, 2008 10:45 am Hanno Böck wrote: Hi, My card is: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (laptop Lenovo T61) When trying to enable uxa (all relevant packages on git head), I get this: http://files.hboeck.de/intel/img_3367.jpg the log: http://files.hboeck.de/intel/Xorg.0.log.uxa This may be the cause(?): (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc008 to 0xd009 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): ESR is 0x0001 (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. No it looks like you're using UXA with tiling enabled. That's not supported at the moment. Really UXA won't be usable until the GTT mapping stuff I've been working on gets merged (still tracking a bug or two in it but I'm almost done other than that), since in order for it to handled tiled regions it needs to map them through a fence register, which is part of mapping it through the GTT. And in order to get decent performance for operations that use software fallbacks, it needs to map framebuffer memory through the GTT rather than mapping the backing store and doing a cache flush for every operation. Anyway, should be working soon... Jesse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] Intel Releases IGD OpRegion Specification
The Intel Open Source Technology Center is pleased to announce the immediate availability of the ACPI Integrated Graphics Device OpRegion Specification[1] under the Creative Commons Attribution-No Derivative Works 3.0 United States License. This document is intended for use by graphics drivers developers and users to enable features such as ambient light sensor support and hotkey-driven display output switching. The IGD OpRegion interface is supported by video BIOS for all Intel® 965 Express Chipset family and newer chipsets. Initial support code is already available for the Linux kernel. The spec includes detailed descriptions of IGD OpRegion functions, APIs, and other interfaces to provide full software support. This release demonstrates Intel's continued commitment to supporting the free software community using the best practices of open source software development. [1] http://www.intellinuxgraphics.org/documentation.html -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: accessing legacy(?) VGA input status register 1 on 945GM/xf86-video-intel
On Monday, September 29, 2008 4:52 am Theo Veenker wrote: Jesse Barnes wrote: On Friday, September 26, 2008 1:36 am Theo Veenker wrote: Jesse Barnes wrote: On Thursday, September 25, 2008 6:00 am Theo Veenker wrote: Hi, I have an application that presents audio-visual stimuli to subjects. To be able to precisely synchronize the audio and graphics the application needs to know when a vsync occurs. My application (from 1994) doesn't yet use libdrm. I'm using a real-time module which (among other things) monitors the vretrace bit in the VGA input status register 1 at 0x3DA and signals the application on each vsync event. It works fine on most graphics hardware. Now I need to make this application work on a laptop with an Intel 945GM. The vretrace bit at IO address 0x3DA doesn't work (under X) unless I connect an external VGA display. Then it works, but it reflects the retrace of the external monitor and not that of the laptop's LCD screen. Since also drmWaitVBlank() didn't work for me on this system, I applied the change hinted in http://lists.freedesktop.org/archives/xorg/2007-June/025166.html to the xf86-video-intel driver (2.4.2). That makes drmWaitVBlank() work (but only after I briefly run a GL application like glxgears first). There's some code in the xf86-video-intel driver to disable vblank interrupts when no 3D client is running (look for want_vblank_interrupts in i830_dri.c, you can either remove the code from I830DRISetVBlankInterrupt or make that field unconditionally true). Maybe that's what you already did. Yes that's what I did. With the stock driver drm vblank would only work while running, for instance, glxgears. After the 'fix' I just need to run glxgears once and after that it works. I can live with that. I understand the LCD screen is on pipe B and the VGA screen on pipe A. Can I somehow swap current behaviour so that when I monitor IO address 0x3DA I can detect vretraces for pipe B instead of for pipe A? That would save me the trouble of hacking DRM into this legacy aplication. I think the status bit in 0x3da will correspond to the pipe VGA is assigned to in VGACNTRL (the headers should have the info you need, if not check out the docs at http://www.intellinuxgraphics.org). Thanks for the info. Here is what I did. In i830_driver.c I830PreInit() below RestoreHWState() I added this: xf86DrvMsg(pScrn-scrnIndex, X_WARNING, HACK: setting VGA_PIPE_B_SELECT.\n); OUTREG(VGACNTRL, pI830-saveVGACNTRL | VGA_PIPE_B_SELECT); Unfortunately the VGA input status register 1 bit 3 still reflects the retraces for the external VGA monitor, instead of the laptop's display panel. So this is problably not correct or I missed something. In Xorg.0.log I read Output VGA is connected to pipe A and Output LVDS is connected to pipe B. Is there a way to swap them, how? And if so would it make a differrence; I mean is it actually possible to have the VGA input status register 1 connected to the LVDS? I think so, but given that we disable VGA mode during normal operation, it may be that you need to have pipe B selected at some point *while* VGA mode is active. OTOH there may be other bits you need to set as well. You could try searching the docs for the string VGA :) I'm afraid I'm clueless here as I am not comfortable with the internals of the driver. Do you mean I need to be running in VGA mode all the time, or do the VGA_PIPE_B_SELECT while temporarily in VGA mode? How would one achive that? I'm not sure, you'd have to play around with it. But if you just want to poll, there's also a bit in the PIPE*STAT regs that indicates whether vblank is active, iirc. Thanks. I'm going to check that as well. From kernel space do I need to call mmap or pci_request_regions etc to gain access to these registers, or can I just access them at the MMIO base address + register offset? They're part of the regular MMIO BAR on this chip, so if you already have that region mapped you can just offset into it to get at the reg. If you haven't already ioremap'd, then yeah you'd have to do that (or just use pci_iomap to get at the right BAR), then use the readX/writeX accessor functions on the resulting pointer. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: accessing legacy(?) VGA input status register 1 on 945GM/xf86-video-intel
On Friday, September 26, 2008 1:36 am Theo Veenker wrote: Jesse Barnes wrote: On Thursday, September 25, 2008 6:00 am Theo Veenker wrote: Hi, I have an application that presents audio-visual stimuli to subjects. To be able to precisely synchronize the audio and graphics the application needs to know when a vsync occurs. My application (from 1994) doesn't yet use libdrm. I'm using a real-time module which (among other things) monitors the vretrace bit in the VGA input status register 1 at 0x3DA and signals the application on each vsync event. It works fine on most graphics hardware. Now I need to make this application work on a laptop with an Intel 945GM. The vretrace bit at IO address 0x3DA doesn't work (under X) unless I connect an external VGA display. Then it works, but it reflects the retrace of the external monitor and not that of the laptop's LCD screen. Since also drmWaitVBlank() didn't work for me on this system, I applied the change hinted in http://lists.freedesktop.org/archives/xorg/2007-June/025166.html to the xf86-video-intel driver (2.4.2). That makes drmWaitVBlank() work (but only after I briefly run a GL application like glxgears first). There's some code in the xf86-video-intel driver to disable vblank interrupts when no 3D client is running (look for want_vblank_interrupts in i830_dri.c, you can either remove the code from I830DRISetVBlankInterrupt or make that field unconditionally true). Maybe that's what you already did. Yes that's what I did. With the stock driver drm vblank would only work while running, for instance, glxgears. After the 'fix' I just need to run glxgears once and after that it works. I can live with that. I understand the LCD screen is on pipe B and the VGA screen on pipe A. Can I somehow swap current behaviour so that when I monitor IO address 0x3DA I can detect vretraces for pipe B instead of for pipe A? That would save me the trouble of hacking DRM into this legacy aplication. I think the status bit in 0x3da will correspond to the pipe VGA is assigned to in VGACNTRL (the headers should have the info you need, if not check out the docs at http://www.intellinuxgraphics.org). Thanks for the info. Here is what I did. In i830_driver.c I830PreInit() below RestoreHWState() I added this: xf86DrvMsg(pScrn-scrnIndex, X_WARNING, HACK: setting VGA_PIPE_B_SELECT.\n); OUTREG(VGACNTRL, pI830-saveVGACNTRL | VGA_PIPE_B_SELECT); Unfortunately the VGA input status register 1 bit 3 still reflects the retraces for the external VGA monitor, instead of the laptop's display panel. So this is problably not correct or I missed something. In Xorg.0.log I read Output VGA is connected to pipe A and Output LVDS is connected to pipe B. Is there a way to swap them, how? And if so would it make a differrence; I mean is it actually possible to have the VGA input status register 1 connected to the LVDS? I think so, but given that we disable VGA mode during normal operation, it may be that you need to have pipe B selected at some point *while* VGA mode is active. OTOH there may be other bits you need to set as well. You could try searching the docs for the string VGA :) But if you just want to poll, there's also a bit in the PIPE*STAT regs that indicates whether vblank is active, iirc. Jesse -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel-2.2.1
Well, it's that time again. Here's the 2.2.1 release. There are many more changes in here than I would have liked, and we still weren't able to close all the blockers (though we did squash quite a few tough ones), but we had to release someday. According to bugzilla, we closed at least a few dozen bugs between 2.2.0 and 2.2.1, but I suspect my bugzilla-fu isn't good enough to get the real list. Thanks a ton to our community testing team, who was diligent about testing the pre-release and herding bugs to the slaughterhouse, and of course the development team and all who contributed fixes. Zhenyu will be handling the 2.3 release, which should include a few new features relative to 2.2 (we're hoping to reduce some of the mode setting flicker that occurs at startup, among other things), and volunteers are welcome to step forward if they'd like to see a 2.2.2 release with a few more bug fixes. And on the policy front, we've decided it's worth spending some time fixing kernel framebuffer related bugs, so if you see problems with this driver running on top of vesafb (intelfb should only be used if you *really* know what you're doing), please report them. We'll probably need register dumps and lots of testing to fix any issues, but we do want to hear about them. Thanks, Jesse Adam Jackson (1): i830_sdvo_mode_valid: Fix return values to match what we actually check. Alan Hourihane (1): vendor is CARD8 Andreas Stawinoga (1): Samsung Q45 has no TV output Dave Airlie (1): ivch: fails on address mismatch as I seem to get this on my 865 system Eric Anholt (1): Remove extra have_libpciaccess=no that broke tools build with old servers. Erik Andren (1): Clevo M720R has no TV-out Hong Liu (4): Bug 10773: fix i8xx pll p2 value in i830_crtc_clock_get() Bug 10584: Mac Mini EDID data assigned to TMDS output Allow non-strict free order for bo_list Fix PLL reference clk debug dump Jesse Barnes (30): Fix typo in 1920x1080 resolution entry Use LEGACY backlight method if backlight control is such Add BCM_ to backlight control method enums Fix backlight setting save/restore Describe output properties in more detail CRT hotplug detection improvements Add cscope files to .gitignore Unconditionally restore pipe configuration Fix compilation error when not using DRI Don't modify low bit of BLC_PWM_CTL when using combo backlight control Add pipe A force enable quirk Add pipe A force enable quirk Don't modify low bit of BLC_PWM_CTL when using combo backlight control Fix compilation error when not using DRI Remove unnecessary quirk code in CRT probing Remove unnecessary quirk code in CRT probing Turn on backlight when LVDS panel is powered up Program FBC fence offset register Only enable FBC if one pipe is active Fix typo in merge Fix build warnings on 64 bit Bump version to 2.2.1.90 for 2.2.1 pre-release Fix version bump, should have been 2.2.0.90 Only disable FBC if registers are available Fix DSP*CNTR restoration Remove side effects from VGA debug code Add pipe A force enable quirk for ThinkPad X40 Add quirk for DVO channel selection Add CACHE_MODE_0 register to dump output Bump version to 2.2.1 Joakim (1): Aopen Minipc 965GM LVDS quirk Julien Cristau (2): Bug 14032: i810, set default depth to 16 Don't build reg_dumper if we don't have pciaccess 0.10.0 Keith Packard (1): Decode DSPCLK_GATE, dump PIPE*STAT, MI_MODE, MI_DISPLAY_POWER_DOWN, MI_ARB_STATE, MI_RDRET_STATE, ECOSKPD Mark Kettenis (1): Bug #14246: Fix biuld on OpenBSD. Michel Dänzer (1): Always set pPriv-buf to NULL after freeing the memory it pointed to. Nanhai Zou (1): TV: fix 576p refresh rate Paulo Cesar Pereira de Andrade (1): Make sure symbols used by other modules are public. Zhenyu Wang (21): Replace ALLOCATE_LOCAL/DEALLOCATE_LOCAL with xalloc/xfree exa: fix rendering issue on some 855GM laptops Fix tv quirk for Dell Latitude X1 Change origin i965G_1 to chipset market name G35. Add new integrated graphics chipset ids GTT access change for new integrated graphics device Update PIPELINE_SELECT instruction and surface state format for new chipset Disable frame buffer compression on new chipset now. Add missing i830M and 845G pci ids info Fix i830 block handler wrap Clear shadow memory after allocation Set vtSema before EnterVT Don't crash if SW cursor Fix last commit on i8xx debug p2 value Bug #14440: fix stolen mem size mask on i830M Fix last 8XX clock's p2 value commit Wrap up chipsets which needs graphics address for status page hardware status page initialization rework Add DMI info for i830 quirks Fix Lenovo X60 TV quirk
[ANNOUNCE] xf86-video-intel-2.1.99
Ok, the first Intel 2.2 pre-release is out, available at the usual locations (e.g. http://xorg.freedesktop.org/archive/individual/driver/). The changelog is fairly large, you can look at git if you really want to see it. For those of you who still have open bugs on the 2.2 blocker list (https://bugs.freedesktop.org/showdependencytree.cgi?id=13027), please give this driver a try and update or close your bugs as appropriate. This driver assumes: - X server 1.4(.x) - Mesa 7.0.x - latest released version of DRM (i.e. latest released Linux kernel for Linux users). Additional suspend/resume fixes are available in development versions of the DRM (in the Mesa DRM tree and recent -mm kernels I believe). There are still several open issues with this release, but bugs are being squashed fairly quickly, so it may shape up into something decent by release time. The main highlights of this release versus 2.1.0 are: - EXA by default (cheers jeers all around please) - Tiled front buffer (should improve performance) - Framebuffer compression (a power saving feature) - Many, many bug fixes (yay!) The final release should have some additional features, including improved backlight support and additional TV output properties, along with many more bug fixes. Many thanks to everyone who's contributed fixes, testing and bug reports so far, please keep up the good work! Thanks, Jesse ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
