[xf86-video-intel] overlay on double wide pipe?
Hello, Will it in future be possible to use xvideo overlays on a pipe in double-wide mode? Or is there any way to prevent the pipe from going into double-wide mode? I have an 1920x1200 second monitor on a Toshiba laptop with an 855GM, running driver version xf86-video-intel-2.5.1-r1 on kernel 2.6.27-gentoo-r7. The pipe for this monitor runs in double wide and I think this is why the overlay is non-functional on this monitor (the empty blue box is displayed). The overlay works if I back the resolution down to 1360x768. GL video works on both displays but stutters. Thank you for the information. -- Shawn C. Powell ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Intel Graphics package and patch requirments
Vasily Khoruzhick wrote on Saturday, January 31, 2009 10:55 PM: > On Saturday 31 January 2009 16:38:09 you wrote: > >> It's not surprising that uxa is not stable in 2.6.0 -- it's not the >> default setting. (we hope uxa would be stabilized in next release) >> >> But did you file bugs for your uxa issues? I only see you've filed >> bug#19738 for the exa performance issue. > > Nope, uxa issues for gma950 was fixed in 2.6.1. Bug #19738 is about > dri2 3D performance, not about EXA. Ah, yes, that bug is about uxa. I just saw you mentioned "with exa it's slow in 3D" in your email. > Btw, with EXA and kernel >= 2.6.28 I can't get 3D working. glxinfo > says that I'm using direct rendering, but ~9fps in quake3 is not > hardware accelerated 3D, is it? Maybe you could file a bug with glxinfo output attached. Thanks Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg 1.5.99.3 with evdev/hal/dbus: keyboard not working
On Sat, Jan 31, 2009 at 3:34 PM, wrote:
> Zitat von Peter Hutterer :
>
>> On Sat, Jan 31, 2009 at 08:38:08PM +0100, mailingli...@openelec.tv wrote:
>>> Hi,
>>>
>>> i am crosscompiling xorg-server 1.5.99.3 with uclibc. xorg (without
>>> xorg.conf, with evdev driver/ hal/ dbus) starts in qemu, mouse works,
>>> but keyboard is not working:
>>>
>>> (EE) XKB: Rules returned no components
>>> (EE) XKB: No components provided for device AT Translated Set 2 keyboard
>>> (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
>>>
>>> i have installed xkeyboard-config-1.5 and xkbcomp
>>>
>>> what is wrong, how i can find the error?
>>
>> Your xkeyboard-config installation looks busted. You don't have a rules
>> directory, which causes the above error. do you have xkeyboard-config 1.4 or
>> later installed?
> i have xkeyboard-config 1.5 installed an i have a rules dir:
>
> /usr/share/X11/xkb/rules/evdev
> /usr/share/X11/xkb/rules/xkb.dtd
> /usr/share/X11/xkb/rules/README
> /usr/share/X11/xkb/rules/base
> /usr/share/X11/xkb/rules/evdev.lst
> /usr/share/X11/xkb/rules/base.lst
> /usr/share/X11/xkb/rules/xfree98
> /usr/share/X11/xkb/rules/evdev.xml
> /usr/share/X11/xkb/rules/base.xml
Did you configure the server to use the XKB rules at
/usr/share/X11/xkb? Normally, it would use ${datadir}/share/X11/xkb,
but you can use --with-xkb-path.
However, I think it's finding the rules and parsing them, but I think
your XKB rules might be messed up like Peter says. It's failing in
XkbRF_GetComponents. Maybe that has something to do with uclibc. You
might have to throw some printf's in that function in xkb/ddxLoad.c if
you're sure that the XKB rules are installed correctly.
--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Sat, 31 Jan 2009 21:41:20 +0100 drago01 wrote: > On Sat, Jan 31, 2009 at 3:30 AM, John Tapsell > wrote: > > 2009/1/31 Bryce Harrington : > >> On Fri, Jan 30, 2009 at 01:29:49PM -0800, Eric Anholt wrote: > >>> > $ glxgears > >>> > Failed to initialize TTM buffer manager. Falling back to > >>> > classic. 300 frames in 5.0 seconds = 59.884 FPS > >>> > 299 frames in 5.0 seconds = 59.621 FPS > >>> > 300 frames in 5.0 seconds = 59.818 FPS > >>> > >>> glxgears is not a benchmark. > >>> > >>> We sync to vblank because running glxgears at 1000fps is dumb. > >> > >> I am going to go out on a limb and guess we're going to see a > >> crapload of reports of "performance regression" due to reduced > >> glxgears frame rates. > > > > What was the purpose in this change? I have never heard a user > > complain that glxgears is running too fast, and that they want it to > > vsync. What's the use case of this change exactly? > > vsync has nothing to do with "glxgears is too fast", but it avoids > tearing in real apps. > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg you can always put something like: in your $HOME/.drirc ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
In message <4984a2e2.8060...@xyzw.org> you wrote: > I'm going to be avoiding 'git format-patch' for a while > now... Or at least 'git send-email'. We really prefer Git-formatted patches, so thanks for doing that. But I, like you, like to compose my own email. Bart ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Initialize event_notify after allocating the memory for it.
Thanks hugely for this catch, Brian! Looks like one of those hard-to-catch things where most of the time it would come back 0, which on most machines is a proper initialization. Pushed. Bart Massey b...@cs.pdx.edu In message <1233427071-19581-2-git-send-email-br...@xyzw.org> you wrote: > An uninitialized or otherwise invalid condition variable can apparently > cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine > at least are freezing as a result of event_notify never being initialized. > > Signed-off-by: Brian Rogers > --- > src/xcb_disp.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/src/xcb_disp.c b/src/xcb_disp.c > index d976064..584380c 100644 > --- a/src/xcb_disp.c > +++ b/src/xcb_disp.c > @@ -94,6 +94,9 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, char > **fullnamep, int *scr > dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); > > dpy->xcb->event_notify = xcondition_malloc(); > + if (!dpy->xcb->event_notify) > + return 0; > + xcondition_init(dpy->xcb->event_notify); > return !xcb_connection_has_error(c); > } > > -- > 1.6.0.4 > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.5.99.902
On Sat, Jan 31, 2009 at 12:55 PM, Keith Packard wrote: > On Sat, 2009-01-31 at 12:18 -0800, Dan Nicholson wrote: > >> I tested Paulo's patch (49b93df8a3002db7196aa3fc1fd8dca1c12a55d6) >> cherry picked to 1.6, and it works fine on Xorg. FWIW, fedora is using >> this patch in rawhide to fix the same issue, and I don't think >> anyone's complained. > > please feel free to stick a link on the wiki and I'll review it for > inclusion. Jeremy put some info in there, but I just put a link to the commit in. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.5.99.902
On Sat, 2009-01-31 at 12:18 -0800, Dan Nicholson wrote: > I tested Paulo's patch (49b93df8a3002db7196aa3fc1fd8dca1c12a55d6) > cherry picked to 1.6, and it works fine on Xorg. FWIW, fedora is using > this patch in rawhide to fix the same issue, and I don't think > anyone's complained. please feel free to stick a link on the wiki and I'll review it for inclusion. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Sat, Jan 31, 2009 at 3:30 AM, John Tapsell wrote: > 2009/1/31 Bryce Harrington : >> On Fri, Jan 30, 2009 at 01:29:49PM -0800, Eric Anholt wrote: >>> > $ glxgears >>> > Failed to initialize TTM buffer manager. Falling back to classic. >>> > 300 frames in 5.0 seconds = 59.884 FPS >>> > 299 frames in 5.0 seconds = 59.621 FPS >>> > 300 frames in 5.0 seconds = 59.818 FPS >>> >>> glxgears is not a benchmark. >>> >>> We sync to vblank because running glxgears at 1000fps is dumb. >> >> I am going to go out on a limb and guess we're going to see a crapload >> of reports of "performance regression" due to reduced glxgears frame >> rates. > > What was the purpose in this change? I have never heard a user > complain that glxgears is running too fast, and that they want it to > vsync. What's the use case of this change exactly? vsync has nothing to do with "glxgears is too fast", but it avoids tearing in real apps. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.5.99.902
On Fri, Jan 30, 2009 at 10:05 PM, Jeremy Huddleston wrote: > We need to do something about the '--enable-builtin-fonts' issue in > 1.6... either change it back to default=no or use Paulo's patch (which > works for me with XQuartz, but I can't verify the xfree86 changes) I tested Paulo's patch (49b93df8a3002db7196aa3fc1fd8dca1c12a55d6) cherry picked to 1.6, and it works fine on Xorg. FWIW, fedora is using this patch in rawhide to fix the same issue, and I don't think anyone's complained. http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.99.3-fix-core-fonts.patch?view=markup https://bugzilla.redhat.com/show_bug.cgi?id=478999 -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
Maarten Maathuis wrote: On Sat, Jan 31, 2009 at 7:37 PM, Brian Rogers wrote: On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. I traced the issue back to an uninitialized condition variable in libX11 xcb code. So to anyone with mysterious freezes, this may be the fix you need. Especially if your backtrace looks like the following one: #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait=) at ../../src/xcb_io.c:141 #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, wait_for_first_event=1, current_error=0x0, current_request=0) at ../../src/xcb_io.c:166 #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at ../../src/xcb_io.c:272 #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, predicate=0x7fb79dd02a70 , arg=0x284 , data1=41943044, data2=0, data3=0) #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, return_value=0x0, n_param_values=1, param_values=0x11d2280, invocation_hint=0x7fffaa4009e0) Was there supposed to be a patch or some other hint attached to this message? Sorry, I was trying out 'git send-email' for the first time (after sending a test-run to myself). It likes to post the patch as a separate mail and I wanted to write my own message separate from the commit message. Then I guess an anti-spam measure delayed delivery of the second e-mail. I'm attaching the patch here to make sure everyone can see it. Also CC'ing Keith Packard because even though I specified him as a CC and the tool repeated a header showing both names I CC'd, it just silently dropped one of them. I'm going to be avoiding 'git format-patch' for a while now... >From 301eefc5376d039b14cf7bb027c610ee276eab33 Mon Sep 17 00:00:00 2001 From: Brian Rogers Date: Sat, 31 Jan 2009 05:24:59 -0800 Subject: [PATCH] Initialize event_notify after allocating the memory for it. An uninitialized or otherwise invalid condition variable can apparently cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine at least are freezing as a result of event_notify never being initialized. Signed-off-by: Brian Rogers --- src/xcb_disp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/xcb_disp.c b/src/xcb_disp.c index d976064..584380c 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -94,6 +94,9 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, char **fullnamep, int *scr dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); dpy->xcb->event_notify = xcondition_malloc(); + if (!dpy->xcb->event_notify) + return 0; + xcondition_init(dpy->xcb->event_notify); return !xcb_connection_has_error(c); } -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
On Sat, Jan 31, 2009 at 7:37 PM, Brian Rogers wrote: > On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. > I traced the issue back to an uninitialized condition variable in libX11 xcb > code. So to anyone with mysterious freezes, this may be the fix you need. > Especially if your backtrace looks like the following one: > > #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 > #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from > /lib/libpthread.so.0 > #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait= optimized out>) at ../../src/xcb_io.c:141 > #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, > wait_for_first_event=1, current_error=0x0, current_request=0) at > ../../src/xcb_io.c:166 > #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at > ../../src/xcb_io.c:272 > #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, > predicate=0x7fb79dd02a70 , arg=0x284 0x284 #6 0x7fb79dd02a39 in IA__gdk_x11_get_server_time > (window=0x135a3f0) at > /build/buildd/gtk+2.0-2.15.0/gdk/x11/gdkevents-x11.c:2598 > #7 0x7fb79e4782f8 in gtk_tray_icon_send_manager_message (icon=0x10d1340, > message=0, window=, data1=41943044, data2=0, data3=0) > #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at > /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 > #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, > return_value=0x0, n_param_values=1, param_values=0x11d2280, > invocation_hint=0x7fffaa4009e0) > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > Was there supposed to be a patch or some other hint attached to this message? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
LibX11/xcb fails to initialize something
On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. I traced the issue back to an uninitialized condition variable in libX11 xcb code. So to anyone with mysterious freezes, this may be the fix you need. Especially if your backtrace looks like the following one: #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait=) at ../../src/xcb_io.c:141 #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, wait_for_first_event=1, current_error=0x0, current_request=0) at ../../src/xcb_io.c:166 #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at ../../src/xcb_io.c:272 #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, predicate=0x7fb79dd02a70 , arg=0x284 , data1=41943044, data2=0, data3=0) #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, return_value=0x0, n_param_values=1, param_values=0x11d2280, invocation_hint=0x7fffaa4009e0) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Initialize event_notify after allocating the memory for it.
An uninitialized or otherwise invalid condition variable can apparently cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine at least are freezing as a result of event_notify never being initialized. Signed-off-by: Brian Rogers --- src/xcb_disp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/xcb_disp.c b/src/xcb_disp.c index d976064..584380c 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -94,6 +94,9 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, char **fullnamep, int *scr dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); dpy->xcb->event_notify = xcondition_malloc(); + if (!dpy->xcb->event_notify) + return 0; + xcondition_init(dpy->xcb->event_notify); return !xcb_connection_has_error(c); } -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Question wrt xf86ReadMmio{8,16}
Hi,
xf86ReadMmio{8,16} both return a 32-bit int. Should the result be zero
or sign extended?
Thanks,
Matt Turner
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel Graphics package and patch requirments
'Twas brillig, and Vasily Khoruzhick at 31/01/09 14:54 did gyre and gimble: > On Saturday 31 January 2009 16:38:09 you wrote: > >> It's not surprising that uxa is not stable in 2.6.0 -- it's not the default >> setting. (we hope uxa would be stabilized in next release) >> >> But did you file bugs for your uxa issues? I only see you've filed >> bug#19738 for the exa performance issue. > > Nope, uxa issues for gma950 was fixed in 2.6.1. Bug #19738 is about dri2 3D > performance, not about EXA. > > Btw, with EXA and kernel >= 2.6.28 I can't get 3D working. glxinfo says that > I'm using direct rendering, but ~9fps in quake3 is not hardware accelerated > 3D, is it? I'm seeing similar issues here too with my 945GM. Kernel 2.6.27 is fine with the same packages... I'll try and dig deeper. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Sat, 2009-01-31 at 15:58 +0100, Michel Dänzer wrote: > > I think a big part of the motivation for client side fonts was indeed > anti-aliasing, so if you don't want AA and core fonts are faster for > you, just use core fonts? > Actually, the data showed that start up time was terribly affected when getting font metrics, and the logistics of deploying new server side font technology was horrific (you got to upgrade both sides of the wire at the same time, which is very tough). The more fonts, the worse it got. The observed fact was that the font metadata had shifted five times over X's history, and we were still stuck on the original broken model. The other issue is subtle: if programmers had to support two code paths in their applications, and AA support is server side only, you get a chicken and egg problem. We were asking app programmers to do additonal work *and* have a long term maintenance headache, while the installed base of those who could take advantage of AA fonts were small. This strategy demonstrably hadn't worked. So keithp wrote Xft so that it would work whether there was server support for glyph caching available or not (screen scraping if necessary). Then app/toolkit writers get to make one set of code modifications, there is a single code path for long term maintenance (*and *from the app/toolkit developers point of view, their testing problems are not multiplied by two). So that strategy was a much easier sell, (not to mention keithp wandering through many of the important projects and proving patches), and the rest, they say, was history. And we are future proofed against the next innovation in font meta data, and got rid of the application start up round trip disaster. See: http://keithp.com/~keithp/talks/usenix2003/ for a fuller explanation and data. - Jim -- Jim Gettys ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?
On Fri, 2009-01-30 at 21:59 +, Nix wrote: > On 30 Jan 2009, Michel Dänzer stated: > >Trying current xf86-video-ati Git might be good, but my main suggestion > >would be to try xserver Git server-1.6-branch with EXA. > > OK. Do I need to upgrade Mesa or anything related at the same time? > (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0). I think that should be fine; if anything 3D related breaks though, you can always try upgrading to Mesa 7.3. :) > >> X: fbFetch_a1 10.92 > >>dixLookupPrivate 7.04 > >>fbStore_a1 3.70 > >>mmxCombineAddU 3.06 > >>pixman_image_composite 2.58 > > > > [...] > > > >> So it looks like we *are* doing huge numbers of fetches from VRAM, > >> judging by the massive time spent in calls upon pixman's fbFetch(). > > > > No, at least with EXA, fb*_a1 can't access video RAM directly, as the > > EXA core currently never migrates pixmaps of bpp < 8 to video RAM. > > This was a profile with XAA, not EXA. Here's a more comprehensive set of > results [...] Ah, so some of those hotspots might indeed be direct VRAM access. With EXA, does it help if you run a compositing manager, even just xcompmgr -a? > I must say, looking at these crude benchmark results I'm wondering if > this client-side font thing wasn't an appealing diversion. Yes, they're > pretty, and more flexible than core fonts: but all of a sudden simply > simply redrawing the screen has become so CPU-intensive that a screen > scroller can peg the CPU without any real effort :( The EXA glyph cache introduced in xserver 1.6 greatly improves rendering of client side fonts - some people have reported in excess of 5 million glyphs/s on beefy Radeons. Unfortunately there are still a couple of cases it doesn't support well in xserver 1.6, hopefully we can fix those for 1.7. > > To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e. > > don't choose any bitmap fonts and don't disable anti-aliasing for small > > font sizes. > > The benchmarks show that this would indeed speed things up. It would > also eliminate every font I use day-to-day and give me piercing > headaches. No thanks, let's find another way. :) I think a big part of the motivation for client side fonts was indeed anti-aliasing, so if you don't want AA and core fonts are faster for you, just use core fonts? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel Graphics package and patch requirments
On Saturday 31 January 2009 16:38:09 you wrote: > It's not surprising that uxa is not stable in 2.6.0 -- it's not the default > setting. (we hope uxa would be stabilized in next release) > > But did you file bugs for your uxa issues? I only see you've filed > bug#19738 for the exa performance issue. Nope, uxa issues for gma950 was fixed in 2.6.1. Bug #19738 is about dri2 3D performance, not about EXA. Btw, with EXA and kernel >= 2.6.28 I can't get 3D working. glxinfo says that I'm using direct rendering, but ~9fps in quake3 is not hardware accelerated 3D, is it? > > and 3D is still unstable in 2.6.1/git master (I still get xserver > > hang - image just freezes - after playing a while in any 3D game). > > I didn't see this issue. Could you file a bug, according to > http://www.intellinuxgraphics.org/how_to_report_bug.html? Can't reproduce it with xf86-video-intel-2.6.1 and latest mesa (I seems latest mesa update fixed it) > Thanks for your testing. Thanks for your work ;) > > Gordon Regards Vasily ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Intel Graphics package and patch requirments
Vasily Khoruzhick wrote on Monday, January 26, 2009 2:57 AM: > On 25 January 2009 20:47:13 Halim Issa wrote: >> Hello, >> >> I am trying to follow Intel Graphics Drivers, among others by >> watching http://intellinuxgraphics.org/2008Q4.html >> >> It would seem that in order to get this to work, one is required to >> patch both mesa (to run intel's mesa branch, not the standard from >> freedesktop?) and also patch the kernel. >> >> Is there any roadmap or wiki available for when these out-of-tree >> patches are due for inclusion in mainline linux kernel (2.6.29 ? >> 2.6.28.nn?) and mainline mesa? So that no patches are needed ? >> >> The reason why I ask is that on Intel's download page this solution >> is listed as the stable and recommended solution for "normal users" >> (such as myself :-)) >> >> >> And finally - is there anywhere a roadmap or todo-list that may show >> when DisplayPort support might be added to the Intel-drivers? >> >> Thanks in advance - any insight or preferably pointers to where this >> information may be located would be greatly appreciated! > > Just want to mention that 2.6.0 is not usable even in 2D on gma950 > with gem/uxa (with exa it's slow in 3D); It's not surprising that uxa is not stable in 2.6.0 -- it's not the default setting. (we hope uxa would be stabilized in next release) But did you file bugs for your uxa issues? I only see you've filed bug#19738 for the exa performance issue. > and 3D is still unstable in 2.6.1/git master (I still get xserver > hang - image just freezes - after playing a while in any 3D game). I didn't see this issue. Could you file a bug, according to http://www.intellinuxgraphics.org/how_to_report_bug.html? > So, IMO, it's unfair to call 2008Q4 release "stable" and "recommended > to ordinary users/OSVs", at least for gma950 users. > > Regards > Vasily Thanks for your testing. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.0
2.6.28-rc8 should work with 2.6.0. But the recommended (newer) kernel includes additional fixes. It's hard to ensure if it'll happen to impact your usage. Gordon -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Cliff Lawson Sent: Saturday, January 17, 2009 1:40 AM To: xorg list Subject: RE: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.0 Gordon, As the i915.ko is part of the kernel development tree now (rather than being built out of the libdrm component) can you confirm whether kernel 2.6.28-rc8 is a late enough version of the kernel to work with this release or should a later kernel version be used? Cliff Lawson -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Jin, Gordon Sent: 15 January 2009 09:09 I've put the related component info and known bugs at http://intellinuxgraphics.org/2008Q4.html. Gordon Scanned by MailDefender - managed email security from intY - www.maildefender.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Intel Graphics package and patch requirments
Halim Issa wrote on Monday, January 26, 2009 2:47 AM: > Hello, > > I am trying to follow Intel Graphics Drivers, among others by watching > http://intellinuxgraphics.org/2008Q4.html > > It would seem that in order to get this to work, one is required to > patch both mesa (to run intel's mesa branch, not the standard from > freedesktop?) and also patch the kernel. > > Is there any roadmap or wiki available for when these out-of-tree > patches are due for inclusion in mainline linux kernel (2.6.29 ? > 2.6.28.nn?) and mainline mesa? So that no patches are needed ? mesa intel-2008-q4-intel branch code is actually a subset of master branch. It forked from master branch at some point, and after that we cherry-picked some patches from master. So the code has already been in mesa upstream. That's basically similar to xv86-video-intel-2.6-branch (or server-1.6-branch) v.s. master. On kernel drm side, we intended to use 2.6.28 kernel. But inevitably there were some (turn out to be 6) patches not catching 2.6.28, so Eric used drm-intel-2.6.28 to maintain them. Later all of these patches went into 2.6.29-rc1 and -rc2, except one patch not necessary to 2.6.29-ish kernel. Hope this clarifies. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xcb-util 0.3.3
xcb-util 0.3.3 is now available, lucky you. git tag 0.3.3 Changelog = Julien Danjou (4): Revert "keysyms: use xcb_key_lookup_t type for col paramter" xcb_keysyms: remove xcb_lookup_t icccm: change class hint struct fields name Release xcb-util 0.3.3 Download http://xcb.freedesktop.org/dist/xcb-util-0.3.3.tar.gz md5: 946bab0980a505958f77d883718c5203 sha1: 1ccce5080ec65456fe1c1ff752e5d0cb3e3dbc4b http://xcb.freedesktop.org/dist/xcb-util-0.3.3.tar.bz2 md5: b1b16c5c1fcf7a6facb346c262cd3513 sha1: a45fe7b4a6af4e0d1d1a876ab91e872cdef2c10b Cheers, -- Julien Danjou // ᐰhttp://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: commit mails for xf86-video-mach64 & -rage128 still say -ati
On Sat, Jan 31, 2009 at 3:17 PM, Alan Coopersmith wrote: > I was confused tonight to get three commit messages for pushes from me to > -ati, until I realized two were for -mach64 & -rage128, just have the > wrong mail subject - one of our local git gurus want to fix the hooks? Done. Dave. > >-alan- > > Alan Coopersmith wrote: >> README | 20 >> 1 file changed, 20 insertions(+) >> >> New commits: >> commit d394e0b8269ea0a7d36ee8edb38947df170399c9 >> Author: Alan Coopersmith >> Date: Fri Jan 30 20:41:43 2009 -0800 >> >> Add README with pointers to mailing list, bugzilla & git repos >> >> diff --git a/README b/README >> new file mode 100644 >> index 000..143816b >> --- /dev/null >> +++ b/README >> @@ -0,0 +1,20 @@ >> +xf86-video-mach64 - ATI Mach64 driver for the Xorg X server >> + >> +Please submit bugs & patches to the Xorg bugzilla: >> + >> +https://bugs.freedesktop.org/enter_bug.cgi?product=xorg >> + >> +All questions regarding this software should be directed at the >> +Xorg mailing list: >> + >> +http://lists.freedesktop.org/mailman/listinfo/xorg >> + >> +The master development code repository can be found at: >> + >> +git://anongit.freedesktop.org/git/xorg/driver/xf86-video-mach64 >> + >> +http://cgit.freedesktop.org/xorg/driver/xf86-video-mach64 >> + >> +For more information on the git code manager, see: >> + >> +http://wiki.x.org/wiki/GitPage >> ___ >> xorg-commit mailing list >> xorg-com...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg-commit > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, Xorg 7.4 and US15W - Poulsbo - please help - I'm stuck
On Fri, 2009-01-30 at 21:35 -0800, Adam Williamson wrote: > On Fri, 2009-01-30 at 21:23 -0800, Alan Coopersmith wrote: > > Adam Williamson wrote: > > > Why is this code being handled in this half-assed way? Can't Intel, > > > Tungsten, Dell, Ubuntu and whoever just pull together and put it in > > > X.org and the kernel like a sane and actually-useful driver should be? > > > > That would be nice - I know some people who went through similar confusion > > a few months ago, and were told by Intel engineers that the > > xf86-video-vermilion that Tungsten contributed to Xorg & DRI about 9 months > > ago is actually the Poulsbo driver, though nowhere else can you find that > > name for it. I never followed up to see if that worked for them on their > > hardware or not. > > I think you're hitting the old "was it really that long ago?" trap :) > > http://cgit.freedesktop.org/xorg/driver/xf86-video-vermilion/ > > Initial commit is dated 2007/03/28 - so *a year* and nine months ago. > I've also read that it's probably the same driver, but even so, it > doesn't help, as it'll be an even earlier version of the code than the > one in Moblin git, which doesn't work. Never mind the one in Ubuntu's > repos. Which also doesn't work (on anything but one specific version of > Ubuntu). > > The 'vermilion' code hasn't been touched in any meaningful way since > April 2007. Just to confirm that vermilion is NOT the driver for Poulsbo (US15W). It's a completely separate device. Alan. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
