Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.99.917
On Sun, Dec 21, 2014 at 14:47:58 +, Chris Wilson wrote: Snapshot 2.99.917 (2014-12-21) == 3 months drifted by whilst I looked elsewhere for bugs.. The highlight of bugs fixed here are a couple of workarounds required for Broadwell and making sure that the rasterisation code is symmetric under inversions. However, as a couple of crashers slipped through into 2.99.916 (though not actual regressions in 2.99.916 per se) and 3 months have passed, we should make one more snapshot before an imminent release. How imminent is imminent? This driver hasn't had a proper release in over a year and a half, this is getting ridiculous... Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void
On Mon, Apr 14, 2014 at 11:22:03 -0700, Keith Packard wrote: By mis-declaring this function, we ended up using software cursors because the value seen by the caller was 0. Signed-off-by: Keith Packard kei...@keithp.com --- src/sna/sna_display.c | 8 ++-- src/sna/sna_display_fake.c | 3 ++- src/uxa/intel_display.c| 7 +-- 3 files changed, 13 insertions(+), 5 deletions(-) Only since http://cgit.freedesktop.org/xorg/xserver/commit/?id=901fbfbbbd71c0d82080957f8ba09eebbc786f2b Which could probably have used a different name to avoid silent breakage. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] compilation broken again
On Tue, Nov 12, 2013 at 22:31:03 +0100, Knut Petersen wrote: is broken again: In file included from sna_accel.c:51:0: /home/knut/fast/xorg/X11-h/usr/include/xorg/shmint.h:59:31: fatal error: protocol-versions.h: No such file or directory compilation terminated. make[4]: *** [sna_accel.lo] Fehler 1 make[4]: Leaving directory `/home/knut/fast/xorg/driver/xf86-video-intel/src/sna' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/home/knut/fast/xorg/driver/xf86-video-intel/src/sna' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/knut/fast/xorg/driver/xf86-video-intel/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/knut/fast/xorg/driver/xf86-video-intel' make: *** [all] Fehler 2 build.sh: make failed on driver/xf86-video-intel build.sh: error processing: driver/xf86-video-intel xserver: 41da295eb50fa08eaacd0ecde99f43a716fcb41a xf86-video-intel: 44c585a1d8c3b603a9c79bf7dfecf420575cfb6 Cause: See xserver bee2ec54049377e0033d49abff20d7bd069c62aa Care to try with http://patchwork.freedesktop.org/patch/15334/ ? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.11-rc7: i915: stuck on render ring
On Thu, Oct 3, 2013 at 22:42:06 +0200, Pavel Machek wrote: On Wed 2013-09-04 11:08:14, Chris Wilson wrote: On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: Hi! I was happily using X... and then screen froze. Mouse still moves. Switching to text console still worked, good. It is first time in a while, normally this machine works well. i915_error_state is attached. Any ideas? It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29). Aha, so I need to update X or rather debian should update the X server. Thanks for the info. Pavel I don't know what version you're running, but stable has 2.19, and unstable has 2.21.15. Both are 2.14.902. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] overlay: fix link error due to missing -lrt
On Mon, Sep 16, 2013 at 15:48:18 -0300, Rodrigo Vivi wrote: CC: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com --- overlay/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/overlay/Makefile.am b/overlay/Makefile.am index 426a3df..c648875 100644 --- a/overlay/Makefile.am +++ b/overlay/Makefile.am @@ -65,4 +65,6 @@ intel_gpu_overlay_SOURCES += \ intel_gpu_overlay_SOURCES += $(both_x11_sources) +intel_gpu_overlay_LDADD = $(LDADD) -lrt + EXTRA_DIST=README Assuming this is about clock_gettime (which really the commit message should say), there should be a configure check. Recent libc doesn't need it. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] configure.ac: Do not include `x11-xcb`, `xcb-dri2` and `xcb-aux` in `XVMCLIB`
On Sun, Feb 3, 2013 at 13:29:04 +0100, Paul Menzel wrote: I was surprised too that no error was generated. Do you have any idea why compilations succeeds? Fails to build here with ../../../src/xvmc/intel_xvmc.c:29:25: fatal error: xcb/xcb_aux.h: No such file or directory Also, shared libraries, as opposed to executable binaries, are allowed to have undefined symbols. Try this: -libIntelXvMC_la_LDFLAGS = -version-number 1:0:0 +libIntelXvMC_la_LDFLAGS = -version-number 1:0:0 -Wl,-z,defs Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: - without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.) I'd expect X to start with vesa or fbdev, rather than erroring out? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] intel: Add support for overriding the PCI ID via an environment variable
On Tue, Feb 21, 2012 at 21:11:07 +, Chris Wilson wrote: On Tue, 21 Feb 2012 12:59:37 -0800, Kenneth Graunke kenn...@whitecape.org wrote: @@ -1828,6 +1829,9 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used, execbuf.rsvd1 = 0; execbuf.rsvd2 = 0; + if (getenv(INTEL_DEVID_OVERRIDE)) + goto skip_execution; I'm not thrilled about calling getenv() for every execbuffer. And what about the original execbuffer path? I'm not thrilled about allowing the user to modify X server behaviour with an env variable. This is setuid root after all. I guess this also applies to the existing calls to getenv in the dri driver. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add branch/sink OUI debugging
On Fri, Jan 13, 2012 at 13:26:08 -0500, Adam Jackson wrote:
DisplayPort lets you discover the manufacturer OUI of the other end.
This is good, because it means you might be able to have per-phy quirks
to work around other people's bugs, but it's bad because it removes some
incentive to not make buggy hardware.
At any rate DisplayPort is proving fickle enough that I'm getting
desperate. Dump the OUI in the log when KMS debug is on.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
include/drm/drm_dp_helper.h |8
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index db3b461..96b3fe2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2097,6 +2097,37 @@ intel_dp_get_edid_modes(struct drm_connector
*connector, struct i2c_adapter *ada
return ret;
}
+static void
+intel_dp_debug_oui(struct intel_dp *dp, uint8_t dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ uint8_t count;
+ int offset;
+ uint8_t oui[3];
+
+ /* not valid in 1.0 */
+ if (dpcd[0] == 0x11)
That looks broken.
Cheers,
Julien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.16.901
On Mon, Oct 31, 2011 at 12:15:45 +1100, Bojan Smojver wrote: On Sun, 2011-10-30 at 16:57 +, Chris Wilson wrote: Bugs fixed in this snapshot (compared to 2.16.0) No hibernation memory corruption fix. Sniff, sniff... :-( Pretty sure what you should be looking for is in the kernel, not the X driver. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 module does not find 82865G if configured as secondary
On Sun, Oct 9, 2011 at 19:36:27 +0100, Chris Wilson wrote: On Sun, 9 Oct 2011 14:44:30 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Oct 09, 2011 at 01:07:25PM +0200, Tempura San wrote: Here is the output of lspci -nn: 00:00.0 Host bridge [0600]: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface [8086:2570] (rev 02) 00:02.0 Display controller [0380]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02) The issue seems to be that the igd isn't a VGA pci class device anymore when used as secondary. The below (untested) patch should allow to still bind the i915 driver. Please test how far that gets us. Note the old kernel, and probable lack of: commit 934f992c763ae1e5eefcce8af769c16444085df7 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Jan 20 13:09:12 2011 + drm/i915: Recognise non-VGA display devices Starting with SandyBridge (though possible with earlier hacked BIOSes), the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior, it would simply disable the integrated GPU. So we adjust our PCI class mask to match any DISPLAY_CLASS device. In such a configuration, the IGFX is not a primary VGA controller and so should not take part in VGA arbitration, and the error return from vga_client_register() is expected. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org and commit 5fe49d86f9d01044abf687a8cd21edef636d58aa Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Feb 1 19:43:02 2011 + drm/i915: Only bind to function 0 of the PCI device Early chipsets (gen2/3) used function 1 as a placeholder for multi-head. We used to ignore these since they were not assigned to PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu systems. This fails hard on gen2/3. Reported-by: Ferenc W??gner wf...@niif.hu Tested-by: Ferenc W??gner wf...@niif.hu Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org I'll try to get these included into a future squeeze kernel update. Thanks. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] glxinfo / glxgears segfault again
On Sat, Sep 17, 2011 at 14:14:39 +0200, Knut Petersen wrote: OpenGL renderer string: Gallium 0.4 on i915 (chipset: 915GM) you likely don't want to be using that. Use the supported classic i915 driver instead. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 6 commits - configure.ac src/sna/gen5_render.c src/sna/Makefile.am src/sna/sna_accel.c src/sna/sna_driver.c src/sna/sna.h src/sna/sna_trapezoids.c
On Mon, Sep 12, 2011 at 22:25:02 +0100, Chris Wilson wrote: On Mon, 12 Sep 2011 23:12:19 +0200, Julien Cristau jcris...@debian.org wrote: Can I please get a way to opt out of this? I build from a git tree, but my .git isn't really something I want to put in my (or other people's) X logs. Doesn't matter a whole lot as long as I'm not building sna, but... Ok, sure. My thoughts were that it would only be useful to people building their own drivers, in which case having a confirmation that they are running the right one is invaluable. Outside of that context, the git id is indeed meaningless. Thanks for the feedback, Right, in that context having the revision show up in the log for confirmation makes perfect sense. Maybe something like the server's --with-builderstring that would default to `git describe` but could be overridden at configure time? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 6 commits - configure.ac src/sna/gen5_render.c src/sna/Makefile.am src/sna/sna_accel.c src/sna/sna_driver.c src/sna/sna.h src/sna/sna_trapezoids.c
Hi Chris, On Fri, Sep 9, 2011 at 08:10:58 -0700, Chris Wilson wrote: commit 2e1bf7e1b44db16d0c322f17535fc6a6fa07353b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Sep 9 12:36:32 2011 +0100 sna: Record git-tree used for compilation Hopefully, I have all the dependencies correct for auto-updating and should continue to work with tarballs... The next step is to perhaps include it in the usual version number, perhaps as patch level? Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk diff --git a/configure.ac b/configure.ac index fbd46a7..089fbdb 100644 --- a/configure.ac +++ b/configure.ac @@ -59,6 +59,14 @@ m4_ifndef([XORG_DRIVER_CHECK_EXT], LT_PREREQ([2.2]) LT_INIT([disable-static]) +# Are we in a git checkout? +dot_git=no +if test -e .git; then $srcdir/.git? (and more in the Makefile.am, $(top_builddir) doesn't really make sense there) + AC_DEFINE(HAVE_DOT_GIT, 1, [Are we in a git checkout?]) + dot_git=yes +fi +AM_CONDITIONAL(HAVE_DOT_GIT, test x$dot_git = xyes) + PKG_CHECK_MODULES(GEN4ASM, [intel-gen4asm = 1.2], [gen4asm=yes], [gen4asm=no]) AM_CONDITIONAL(HAVE_GEN4ASM, test x$gen4asm = xyes) Can I please get a way to opt out of this? I build from a git tree, but my .git isn't really something I want to put in my (or other people's) X logs. Doesn't matter a whole lot as long as I'm not building sna, but... Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Thu, Jul 21, 2011 at 13:54:41 +, Ben Widawsky wrote: On Tue, Jul 19, 2011 at 11:06:17PM +0200, Julien Cristau wrote: On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: +#define SHADER_DEBUG_SOCKET /tmp/gen_debug Not sure what this is used for, but does it really need to be in /tmp? It is the shared socket between a debug client (ie. Mesa) and the debugger. I don't care where it goes, do you have any recommendations? Somewhere under $HOME is probably better than a predictable file name in /tmp. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: +#define SHADER_DEBUG_SOCKET /tmp/gen_debug Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: hangcheck disable parameter
On Tue, Jun 28, 2011 at 17:09:54 -0700, Ben Widawsky wrote: Provide a parameter to disable hanghcheck. This is useful mostly for developers trying to debug known problems, and probably should not be touched by normal users. Something like this could maybe find its way into a MODULE_PARM_DESC? Actually it looks like none of the i915 parameters have a description :( Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 3 commits - src/intel_display.c src/intel_dri.c src/intel.h
On Thu, Mar 24, 2011 at 16:52:25 -0700, Keith Packard wrote:
On Thu, 24 Mar 2011 19:31:03 +0100, Julien Cristau jcris...@debian.org
wrote:
This will cause a double free as the blit_fallback path does it too.
Argh! So we need to check before we reference the buffers and set
swap_info to NULL. This code is too twisty...
@@ -955,11 +960,16 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr
draw, DRI2BufferPtr front,
swap_info-event_data = data;
swap_info-front = front;
swap_info-back = back;
+
+ if (!i830_dri2_add_frame_event(swap_info)) {
+ free(swap_info);
+ swap_info = NULL;
+ goto blit_fallback;
+ }
+
I830DRI2ReferenceBuffer(front);
I830DRI2ReferenceBuffer(back);
- i830_dri2_add_frame_event(swap_info);
-
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
if (pipe 0)
With that change,
Reviewed-by: Julien Cristau jcris...@debian.org
Thanks!
Julien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 3 commits - src/intel_display.c src/intel_dri.c src/intel.h
Hi Keith,
a couple suggestions below from a quick look over these patches.
On Wed, Mar 23, 2011 at 17:24:57 -0700, Keith Packard wrote:
commit e1ff5182304e00c0d392092069422cae7626cf8d
Author: Keith Packard kei...@keithp.com
Date: Wed Mar 9 17:00:41 2011 -0800
Handle drawable/client destruction in pending swaps/flips
A pending swap or flip holds references to drawables and clients which
become invalid when destroyed. Add suitable resources to the database
to track those lifetimes and clean up the pending data structure then.
Later, when the pending swap or flip occurs, handle a missing drawable
by just discarding the flip or swap. Handle a missing client by not
sending an event or reply.
Signed-off-by: Keith Packard kei...@keithp.com
[...]
diff --git a/src/intel_display.c b/src/intel_display.c
index eb07cf5..4734844 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -1512,7 +1512,7 @@ static const xf86CrtcConfigFuncsRec
intel_xf86crtc_config_funcs = {
static void
intel_vblank_handler(int fd, unsigned int frame, unsigned int tv_sec,
-unsigned int tv_usec, DRI2FrameEventPtr event)
+unsigned int tv_usec, void *event)
This seems to just revert a change from the previous commit?
{
I830DRI2FrameEventHandler(frame, tv_sec, tv_usec, event);
}
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 9e8c370..f039e9d 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -577,6 +577,69 @@ I830DRI2DrawablePipe(DrawablePtr pDraw)
[...]
+/*
+ * Hook this frame event into the server resource
+ * database so we can clean it up if the drawable or
+ * client exits while the swap is pending
+ */
+static Bool
+i830_dri2_add_frame_event(DRI2FrameEventPtr frame_event)
+{
+ frame_event-client_id = FakeClientID(frame_event-client-index);
+
+ if (!AddResource(frame_event-client_id, frame_event_client_type,
frame_event))
+ return FALSE;
+
+ if (!AddResource(frame_event-drawable_id, frame_event_drawable_type,
frame_event))
+ return FALSE;
+
+ return TRUE;
+}
+
+static void
+i830_dri2_del_frame_event(DRI2FrameEventPtr frame_event)
+{
+ if (frame_event-client_id)
+ FreeResourceByType(frame_event-client_id,
frame_event_client_type, FALSE);
+ if (frame_event-drawable_id)
+ FreeResourceByType(frame_event-drawable_id,
frame_event_drawable_type, FALSE);
+}
+
static void
I830DRI2ExchangeBuffers(DrawablePtr draw, DRI2BufferPtr front,
DRI2BufferPtr back)
@@ -642,11 +705,18 @@ I830DRI2ScheduleFlip(struct intel_screen_private *intel,
flip_info-event_data = data;
flip_info-frame = target_msc;
+ i830_dri2_add_frame_event(flip_info);
+
if (!i830_dri_add_frame_event(flip_info))
return FALSE;
?
/* Page flip the full screen buffer */
back_priv = back-driverPrivate;
- return intel_do_pageflip(intel,
- intel_get_pixmap_bo(back_priv-pixmap),
- flip_info, ref_crtc_hw_id);
+ if (intel_do_pageflip(intel,
+ intel_get_pixmap_bo(back_priv-pixmap),
+ flip_info, ref_crtc_hw_id))
+ return TRUE;
+
+ i830_dri2_del_frame_event(flip_info);
+ free(flip_info);
+ return FALSE;
}
static Bool
[...]
@@ -876,6 +958,8 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr draw,
DRI2BufferPtr front,
I830DRI2ReferenceBuffer(front);
I830DRI2ReferenceBuffer(back);
+ i830_dri2_add_frame_event(swap_info);
+
if (!i830_dri2_add_frame_event(swap_info)
goto blit_fallback;
?
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
if (pipe 0)
[...]
Cheers,
Julien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote: [Digression: what is upowerd doing reading those power hungry files?] Apparently, checking docked status every 30 seconds, by reading the status of drm outputs. Where docked means more than one output connected. Yes, it's silly. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Trying to compile drivers to the Acer Aspire One 532h
On Sun, Feb 27, 2011 at 13:45:20 -0300, Nicolau Werneck wrote: $ sudo grep -i glx\|drm /var/log/Xorg.0.log (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: glx (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=FireGL - ATI Technologies Inc. (II) Loading extension GLX You need to get rid of fglrx. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel 2.14.0 on Oracle Solaris 11 Express find no screens
On Thu, Feb 24, 2011 at 11:11:55 -, Marco A. Ferra wrote: Dear intel-gfx group, Perhaps you can give me some assistance. I have installed the Oracle Solaris 11 Express operating system on an Intel Atom CPU D510 that has a Pineview Integrated Graphics Controller (PineView-D). However, it seems that X doesn't detect any screens with intel's module driver. I have compiled the latest version (2.14.0) and even so it can't detect any screens. With vesa the X starts up and works fine, but displays a limited resolution of 1280x1024. I would like to know if any of you can give me any tips on how to resolve this apparently simple problem. I believe that could be something with outdated drivers or dependences (?) or even missing ones. Recent versions of the intel X driver require kernel mode setting, which is only available on linux at this point. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] xf86-video-intel: Update autotools configuration
On Wed, Feb 9, 2011 at 11:30:50 +, Javier Jardón wrote: Hello, here another patch to update the autotools configuration of the xf86-video-intel package It uses the new libtool syntax and the new silent build mode. XORG_DEFAULT_OPTIONS already enables the silent mode, iirc. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intel-gfx][intel-gpu-tools][patch] Review of some patches to get rid of some compile warnings
On Wed, Feb 9, 2011 at 18:00:34 +, Diego Celix wrote: Hello, I've been doing some little modifications of the code of the intel-gpu-tools package to get the compile warnings fixed. I've divided those changes in little commits. The 0001 patch file fixes these warnings: intel_disable_clock_gating.c:38: warning: unused variable 'temp' intel_bios_reader.c:192: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int' You should include this information (the warning messages that you fixed) in the commit messages themselves. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] QS57/HD Graphics support?
On Sat, Dec 4, 2010 at 11:23:19 +, Alberto Di Meglio wrote: Of course I'm more than willing to test it, however I need some hint. I've downloaded the drm-intel-staging snapshot from git and I tried to compile the drm module against my current kernel headers, but I get the error unknown field 'cmd_drv' specified in initializer. Should I build the full kernel? Yes. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: fix headers to include linux/types.h
On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote: For headers that get exported to userland and make use of u32 style type names, it is advised to include linux/types.h. This fixes 5 headers_check warnings. How many times does this need to be NAKed? These headers are shared with the BSDs, and they include drm.h which has the linux/types.h include on linux already. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Installing/Compatability
On Mon, Oct 25, 2010 at 02:15:45 -0400, marcus cox wrote: would this process work with your drivers as well? if not, what is the exact process, or where on your site can i find it. No. You just get the drivers from your distribution, so stuff works out of the box without having to go download the drivers after install. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.12.901 (2.13 rc1)
On Wed, Sep 22, 2010 at 13:12:44 +0200, Sven Joachim wrote: On 2010-09-22 02:48 +0200, Carl Worth wrote: This is the first release candidate in preparation for the upcoming 2.13.0 release. We will appreciate any feedback we can get from testing of this snapshot. It fails to build here with libdrm 2.4.21 because DRM_MODE_CONNECTOR_eDP is not #defined, so you may want to ensure that libdrm 2.4.22 gets released soon (commit b8abe6139e5c6779ee87d983346f0f65bf67462e in libdrm seems to take care of the problem, but I haven't tested that yet). 431f7f00db844534dbcf9a63da0d2832a3d91bff is the needed commit (I cherry-picked that a couple of days ago to Debian's libdrm so I could build the intel driver). Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, Jul 27, 2010 at 17:39:11 +0100, Daniel Stone wrote: arjan In file included from /usr/include/xorg/scrnintstr.h:58:0, arjan from /usr/include/xorg/xf86str.h:39, arjan from /usr/include/xorg/xf86.h:46, arjan from uxa-priv.h:37, arjan from uxa.c:37: arjan /usr/include/xorg/dix.h:57:31: fatal error: X11/extensions/XI.h: No such file or directory That would be a dep on inputproto. :) xi only gives you XInput.h and XInput2.h, both client-only headers. And it's already fixed. http://cgit.freedesktop.org/xorg/xserver/commit/?id=32c706c4ffd7433dbfc79dba8785b1510d2f053f The GL one is more annoying. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] funny lines in X applications and /dev/agpgart missing
On Tue, Jul 13, 2010 at 16:29:37 +1000, Huaxin Xu wrote: Hi, My X windows application shows some funny lines after being launched. Please find kernel .config, Xorg.conf and Xorg.log in the attachments. Setup: Desktop, motherboard: GA-G41MT-ES2L (with G41 chipset), Monitor SAMSUNG, Fedora 8, Intel driver: 2.5.0. I noticed /dev/agpgart is missing and X complained about drmOpen failed and DRI disabled. I am not sure if these behavior are relevant. Support for the G41 chipset was added to intel-agp in 2.6.29. Use a slightly less old kernel. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901
On Tue, Jun 15, 2010 at 16:05:15 +0200, Marc Deop i Argemà wrote: On Tuesday June 15 2010 02:39:54 Carl Worth wrote: This is the first release candidate in preparation for the upcoming 2.12.0 release. We will appreciate any feedback we can get from testing of this snapshot to improve the 2.12.0 release. It makes my system really unstable. Sometimes I can't even login :S The system just freezes :( I'm running archlinux, Mesa 7.8.1, libdrm 2.4.21, Xorg-server 1.8.1.901, kernel 2.6.34. On what hw? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
