Re: How to shift color bits in fbdev?
On Son, 2009-03-15 at 11:08 -0700, Gregoire Gentil wrote: - the background is still with a darken opacity - the problem around the transparent icons have disappeared - the png background of the bottom panel has the exact perfect colors (no opacity problem) and it's a complex png shading background. - The icons in the start menu have 95% of the right colors. FWIW, if you aren't going to use hardware acceleration, then the shadow layer (and fixing up the pixel format in the shadowUpdate hook) is probably a better solution than wfb. -- 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: [ANNOUNCE] xf86-video-intel 2.6.99.902
'Twas brillig, and Carl Worth at 11/03/09 00:37 did gyre and gimble: This release is a tiny change compared to .901. The only difference is that the tar file now includes the files necessary to build and link the driver against xvmclib. Thanks to Stefan Dirsch and Donnie Berkholz for reporting and confirming the problem with the previous tar file. git tag: xf86-video-intel-2.6.99.902 Is this tag format deliberate? I thought the last stable release dropped the xf86-video-intel- prefix? 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
Recommended X versions for Mobile Intel® GM45 Express Chipset
Hello, I have been trying to stay current on the recent intel drivers, xorg-server,mesa and dri for a while and have most likely due to lack of experience suffered a rather unstable system. Thus I'd like to revert to the most stable solution. Does anyone have a quick pointer to what is the earliest and most tested versions of xorg-server, mesa and dri that will work with an intel driver supporting Mobile Intel® GM45 Express Chipset on a Lenovo X200 ? Will for instance Xorg-server 1.4.2 function with a version of the intel driver that supports my chipset? Thanks in advance for any help on novice question. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16, Beso givemesug...@gmail.com: 2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso sorry, i forgot the script. -- dott. ing. beso radeonhd-updater-modified.sh Description: Bourne shell script ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Adding support for a (multi-)touchscreen - where best to add it?
On Mon, 2009-03-16 at 11:05 +1000, Peter Hutterer wrote: that's probably because they advertise a button/axis combination that evdev does interpret correctly, or because they're posting the axis information wrongly. I had my hands on an HP Touchsmart for a short while and it was posting x/y through Z/Rx. Yes, that is also what I was seeing with the 3M. Either this means that evdev needs a good way to remap pointer axis based upon HAL data (so that you could set up the .fdi) OR evdev need enough smarts to say IF device is touchscreen AND device does not report X/Y axis THEN remap whatever axis device does report and log device is stupid. sort-of. except that there's a huge difference between multi-touch, multi-point and multi-touch-multi-point. ... touch: not a single point, but a single area. touching with a thumb is different than touching with a stylus. touch screens that only to single point interaction are technically no different to a mouse. This is what I am interested at this moment: the screen I am working with returns a rectangle for the touch area. Oh, and there's also some fun in providing touch support in standard apps that think that your fingers are a mouse. Cheers, Peter PS: google for multi-touch demonstration and try to find one that doesn't just use one full-screen app. Not a lot of them around. Again, in my case this is not a big issue, as this is in support of a full-screen application (embedded system, though not as most people think of as embedded as the device in question is pretty large in size and in computing power). Again, I'm just trying to map out the most direct route from what I have to what will work (without making too many stupid decisions along the way) - That's why I am beginning to thing that maybe tslib might be the better medium term approach, as I can do all the fiddly-bits (e.g. sending the special wakeup packet to the panel, parsing the funny packet back) from user space rather than kernel space, even though long term the better place might be in the kernel + evdev. I've also added my work email so I can see these at work - unfortunately I really cannot use my work email for sending to the list as the Corporate Lawyers insist upon a half-page wart being added at the mail server. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.99.901
'Twas brillig, and Carl Worth at 10/03/09 01:54 did gyre and gimble: Here is the first release candidate in preparation for the upcoming 2.7.0 release. What is the (rough) timescale for the first 2.7.x release? All changes from 2.6.0 to 2.6.99.901 Does it not make more sense to list the differences between 2.6.3 and 2.6.99.901? -- 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
Redirect USB keyboard to something
Hello, I have an usb barcode reader that X recognize as a keyboard. But I want to create an application which work on the output from this barcode. With the actual solution, I need my apps and a specific entry field to have the focus, this is not an interesting solution because the event trigered by the input from the barcode does not more user actions, so the user can be on his webnavigator, want to scan a barcode without leaving his navigator, let the computer react to the event, and continue his navigation. Some barcode reader allow to use 'serial emulation', which can solve my problem (I connect my apps to the serial port and read data without bothering the user). Unfortunately, my device does not have this option. So, my question is, do you know a way (between hal, evdev, X) or an other (kernel, but if it the case, sorry for asking here) to transform an 'usb keyboard' to something like a file device that I can read 'easily' from an application. Thank everybody -- Guillaume ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Dual screen on ATI 9600 | NV350 AQ using radeon driver - clone only ?
I have to identical monitors running at 1280x1024. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm S-video disconnected (normal left inverted right x axis y axis) The first problem was the Virtual size was too small to fit two of both outputs, so that got configured in xorg.conf. Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2560 x 1024 So now I should be ready for running dual screen ? torbj...@torbjorn-desktop:~$ xrandr --dryrun --output DVI-0 --right-of VGA-0 screen 0: 2560x1024 675x270 mm 96.33dpi crtc 0:1280x1024 60.0 +1280+0 DVI-0 VGA-0 The result of doing this is that both outputs end up with the same offset, in effect, I can only see the right side of the virtual screen. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm I have tried lots of different ways to get them to show the whole virtual screen, including using --pos, but I can't get them to split. The outputs always see the same area of the virtual screen. If anybody could point me in the right direction, I would be very grateful. -- Torbjørn ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Window content update benchmark (code review)
Hi,
Here is some code for reviews.
This program tries to benchmark window update using X11 + extensions
requests. The program uses Xlib functions such as XPutImage(),
XCopyArea(), XRender function XRenderComposite(), Pixmap, MIT-SHM shared
memory, shared memory Pixmap, etc.
The purpose of the program is to show how ARGB32 visual, composite
manager, drivers and shared memory interact between each others on
different hardware/driver configuration.
Running this program on different system configuration will show that
hardware and driver configuration (for example a nvidia card with X.org
driver vs proprietary driver) affect window update performance, which is
especially true regarding shared memory pixmap.
BTW, I'm sure I made some mistake and forgot some efficient/clever ways
of updating window content. Feel free to comment/improve this little
program.
Example, running on 855GM adapter, using intel_drv version 2.4.2
Composite: 0.4
Render: 0.10
MIT-SHM: 1.1
event 19
Can't set priority, harmless: Permission denied
Can't set scheduler, harmless: Operation not permitted
Can't lock memory, harmless: Cannot allocate memory
event 15
event 12
1: XPutImage(XImage): 6.842764797
2: XPutImage(XImage): Pixmap, XCopyArea(Pixmap): 10.318757087
3: XPutImage(XImage): Pixmap, XRenderComposite(Pixmap): 10.241974700
4: XShmPutImage(XImage SHM): 4.224114416
5: XShmPutImage(XImage SHM): Pixmap, XCopyArea(Pixmap): 6.694422568
6: XShmPutImage(XImage SHM): Pixmap, XRenderComposite(Pixmap):
6.575778511
7: XCopyArea(Pixmap SHM): 3.993095927
8: XRenderComposite(Pixmap SHM): 3.805270309
Regards
--
Yann Droneaud
/**
* @file benchimagemark.c
* @brief Benchmark methods to update window content
*
* @date 2009-01-16 created
* @author Yann Droneaud ydrone...@mandriva.com
*
* Note: When compositing is enabled,
* the window content below could impact the results
* It's really better if this content does not change during
* the test.
*
* Compile/Link:
* gcc -std=c99 -g -O2 \
* -Wextra -Wall \
* -I/usr/X11R6/include \
* -L/usr/X11R6/lib -lX11 -lXext -lXrender -lXcomposite -lrt \
* -o benchimagemark benchimagemark.c
*
*/
/*
* Copyright (C) 2009 Mandriva SA
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
*/
#define _POSIX_SOURCE
#define _XOPEN_SOURCE 600
#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE_EXTENDED
#define _ISOC99_SOURCE
#include stdint.h
#include stdlib.h
#include stdio.h
#include sys/types.h
#include unistd.h
#include X11/Xlib.h
#include X11/extensions/Xrender.h
#include X11/extensions/Xcomposite.h
#include sys/ipc.h
#include sys/shm.h
#include X11/extensions/XShm.h
#include errno.h
#include string.h
#include assert.h
#include time.h
#include sys/mman.h
#include sys/time.h
#include sys/resource.h
#include sched.h
/**
* @brief substract two timespec values and store the result
*
* @param[out] res
* @param[in] before
* @param[in] after
*
*/
static inline void
timespec_substract(struct timespec *res,
const struct timespec *before,
const struct timespec *after)
{
*res = *after;
if (res-tv_nsec before-tv_nsec) {
res-tv_sec -= 1;
res-tv_nsec += (10L) - before-tv_nsec;
} else {
res-tv_nsec -= before-tv_nsec;
}
res-tv_sec -= before-tv_sec;
}
static Display *display = NULL;
static Window root = None;
static Window window = None;
static Visual *visual = NULL;
static XGCValues gcvalues;
static GC gc = None;
static XImage *ximage = NULL;
static XImage *shmximage_ximage = NULL;
static XImage *shmximage_pixmap = NULL;
static Pixmap pixmap = None;
static Pixmap shmpixmap = None;
static uint8_t *data = NULL;
static uint8_t *shmdata_ximage = NULL;
static uint8_t *shmdata_pixmap = NULL;
static Picture pixmap_pict;
static Picture shmpixmap_pict;
static Picture window_pict;
/* test id */
static int test = 0;
static void
flush_xevent(Display *d)
{
/* flush events */
for(;;) {
XEvent e;
/* check X event */
if (!XPending(d)) {
break;
}
XNextEvent(d, e);
printf(event %d\n, e.type);
}
}
/**
* Number of window updates per test
*
*/
#define BENCHMARK_RUN 1
/**
* start a test:
* check for condition,
* ensure all requests and events are processed
* start clock
* run the test
*/
Re: [ANNOUNCE] xf86-video-intel 2.6.99.901
On Mon, 2009-03-16 at 11:47 +, Colin Guthrie wrote: 'Twas brillig, and Carl Worth at 10/03/09 01:54 did gyre and gimble: Here is the first release candidate in preparation for the upcoming 2.7.0 release. What is the (rough) timescale for the first 2.7.x release? A few weeks or so. We've got an intel-2d-release bug for preparing for this, but I think it currently has several bugs on it that will not feasibly be fixed. I plan to make that list more reasonable soon, at which point tracking that bug will be much more useful. All changes from 2.6.0 to 2.6.99.901 Does it not make more sense to list the differences between 2.6.3 and 2.6.99.901? I think this is a case where the version-numbering scheme doesn't make it very obvioous what's actually going on with the code. The 2.6.3 release was made from an earlier branch (2.6) than 2.6.99.90 (which is from the 2.7 branch). Maybe even then it would have made sense to list the changes from 2.6.3 to 2.6.99.01. But I don't know of a trivial way to generate such a list. It would be misleading to take the output of something like git log 2.6.3..2.6.99.901 since that would list several bug fixes as being new since 2.6.3 when in fact the same fixes were already cherry-picked to the 2.6 branch and were present in 2.6.3. Any suggestions are welcome though. -Carl 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: Dual screen on ATI 9600 | NV350 AQ using radeon driver - clone only ?
On 3/16/09, Torbjørn Thorsen - Nextline torbj...@nextline.no wrote: I have to identical monitors running at 1280x1024. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm S-video disconnected (normal left inverted right x axis y axis) The first problem was the Virtual size was too small to fit two of both outputs, so that got configured in xorg.conf. Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2560 x 1024 So now I should be ready for running dual screen ? torbj...@torbjorn-desktop:~$ xrandr --dryrun --output DVI-0 --right-of VGA-0 screen 0: 2560x1024 675x270 mm 96.33dpi crtc 0:1280x1024 60.0 +1280+0 DVI-0 VGA-0 The result of doing this is that both outputs end up with the same offset, in effect, I can only see the right side of the virtual screen. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm I have tried lots of different ways to get them to show the whole virtual screen, including using --pos, but I can't get them to split. The outputs always see the same area of the virtual screen. If anybody could point me in the right direction, I would be very grateful. Both outputs are probably ending up on the same crtc by default (use xrandr --verbose to verify). So you probably want something like: xrandr --output DVI-0 --crtc 1 --mode 1280x1024 --right-of VGA-0 This page has a lot of good information about configuration using xrandr: http://wiki.debian.org/XStrikeForce/HowToRandR12 Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86OSMouseInit() not used
Using xf86-input-mouse-1.4.0 without any configuration.
(EE) default pointer: No Protocol specified
(EE) PreInit failed for input device default pointer
(II) UnloadModule: mouse
How can I get more logging or details for this?
ktrace didn't tell me anything extra.
Now I see the source and looking at mousedrv.4 manpage which says
specifying the protocol option is mandatory. But I don't think that is
documented correctly as Xorg will startup without any config with working
mouse on some systems.
I tried running Xorg -logverbose 199 but that didn't give me extra details
related to this.
I am using NetBSD. I added various logging to the bsd_mouse.c and realized
it wasn't even used. I even renamed functions in there too.
The mouse_drv includes the bsd_mouse.o. I see that at build time and I can
see my extra debugging when looking at the driver library,
Now I realize it is using the same functions from my old xorg-server
1.4.2. If something changed in xorg-server since then, shouldn't
xf86-input-mouse depend on newer xorg-server?
(I am still researching ...)
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr'#-~''\-.-{'
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: No fragment shader?
On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Monday 16 March 2009, Beso wrote: 2009/3/16, Beso givemesug...@gmail.com: 2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso sorry, i forgot the script. I enabled that .configure line before I ran it since this is kde-4.2. This error eventually: building mesa *** autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf autoreconf: configure.ac: not using Autoheader autoreconf: configure.ac: not using Automake autoreconf: Leaving directory `.' checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gmake... gmake checking for makedepend... /usr/bin/makedepend
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: How to shift color bits in fbdev?
Michel, Problem fixed. Patching the line *win++ = (*sha++)2; in shadowUpdatePacked of shpacked.c made the trick. It was just adding three characters! Many thanks to Maarten and Daniel for their help though I didn't manage to make it work with wfb. I don't know what I'm doing wrong on this patch - The patch in the thread may be useful to somebody else perhaps. Thanks to Michel for bringing the quick and dirty solution, Grégoire P.S.: Hey Michel, next time, please answer before the week-end. That will spare me the 200 tries with xf86-video-fbdev on Saturday and Sunday night when I'm successful at the first try with xorg-server ;-) ;-) On Mon, 2009-03-16 at 07:58 +0100, Michel Dänzer wrote: On Son, 2009-03-15 at 11:08 -0700, Gregoire Gentil wrote: - the background is still with a darken opacity - the problem around the transparent icons have disappeared - the png background of the bottom panel has the exact perfect colors (no opacity problem) and it's a complex png shading background. - The icons in the start menu have 95% of the right colors. FWIW, if you aren't going to use hardware acceleration, then the shadow layer (and fixing up the pixel format in the shadowUpdate hook) is probably a better solution than wfb. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Redirect USB keyboard to something
If you are on linux and using Xorg's evdev driver for keyboard input,
you can configure evdev to ignore that keyboard. Your app can, then,
directly read that keyboard using the same kernel API evdev uses:
char special files /dev/input/{1..31}.
I don't know whether it is possible on other platforms, especially
when X's keyboard driver is used for keyboard input.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-savage: Fix crash by null pointer access on XVideo when DRI is not available
The Linux kernel version 2.6.29-rc7 introduced a regression that makes a
mmap2() call on /dev/dri/card0 fail with EAGAIN on Savage chipsets
(don't know about other chipsets yet). I have not yet bisected it or
filed a bug for it (since I want to check 2.6.29-rc8 for this bug), but
this in turn uncovered a bug in my recent changes to the savage driver.
When DRI is not available, an attempt to query available memory for
xvideo via AGP (which requires DRI) results in a NULL pointer access to
psav-DRIServerInfo, even if xvideo is configured not to use AGP. This
patch fixes it by adding a NULL pointer check that allows it to use the
previously-available framebuffer upload for xvideo while I hunt down
this bug.
Changelog:
* Add NULL pointer check before trying to access DRIServerInfo, since it
might be NULL when DRI fails to initialize.
--
perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From ce37ca3de7aa80f176295ad8d5ace111ec2a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= a...@karlalex.palosanto.com
Date: Sat, 14 Mar 2009 21:34:48 -0500
Subject: [PATCH] Fix crash by null pointer access when DRI is not available.
---
src/savage_video.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/savage_video.c b/src/savage_video.c
index 57483e0..bccb801 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -1965,7 +1965,7 @@ SavagePutImage(
/* Check whether AGP buffers can be allocated. If not, fall back to
ordinary
upload to framebuffer (slower) */
-if (!pPriv-tried_agp !psav-IsPCI psav-drmFD 0) {
+if (!pPriv-tried_agp !psav-IsPCI psav-drmFD 0
psav-DRIServerInfo != NULL) {
int ret;
SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does xcb really need python?
In message 20090316055209.ga4...@comet you wrote: On 07:48 Sun 15 Mar , David Wuertele wrote: I tried compiling libX11-1.2 but it asked for libxcb-1.1.92 or newer. I tried compiling libxcb-1.1.92 but it asked for python-2.5 or newer. Because of the crazy package dependencies in my workstation, upgrading its python-2.3 to python-2.5 is impossible (hooray for outsourced IT). Also, my build script has to work for dozens of developers who have the same python version as me and the same inability to upgrade. I forced libxcb's configure script to accept my python version, but then libxcb died during the build due to the incompatibility. Stymied by the python requirement, I tried backing down to libxcb-1.1 which doesn't require it. That compiled fine. But now I had to back down to libX11-1.1. libX11-1.1's build failed due to what appears to be a known bug. Googling says that the only cure is to go to libX11-1.2! This should do the trick with libX11: ./configure --without-xcb Also, the Python is only used to generate some generic C code. So if you want to stick with Xlib/XCB, just build xcb/proto and xcb/libxcb on some machine with newer Python and copy the generated C files over. You should maybe file a couple of bugs against XCB: one about not shipping generated C, and one about requiring new-ish Python. I'm thinking offhand that the right fix for the generated C bug is to have a separate package (or two) available with current generated files in it. We may not be able to reasonably fix the Python one, depending on how much damage it would require to the current Python code). Bart Massey b...@cs.pdx.edu ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does xcb really need python?
On Mon, Mar 16, 2009 at 12:09 PM, Barton C Massey b...@cs.pdx.edu wrote: In message 20090316055209.ga4...@comet you wrote: On 07:48 Sun 15 Mar , David Wuertele wrote: I tried compiling libX11-1.2 but it asked for libxcb-1.1.92 or newer. I tried compiling libxcb-1.1.92 but it asked for python-2.5 or newer. Because of the crazy package dependencies in my workstation, upgrading its python-2.3 to python-2.5 is impossible (hooray for outsourced IT). Also, my build script has to work for dozens of developers who have the same python version as me and the same inability to upgrade. I forced libxcb's configure script to accept my python version, but then libxcb died during the build due to the incompatibility. Stymied by the python requirement, I tried backing down to libxcb-1.1 which doesn't require it. That compiled fine. But now I had to back down to libX11-1.1. libX11-1.1's build failed due to what appears to be a known bug. Googling says that the only cure is to go to libX11-1.2! This should do the trick with libX11: ./configure --without-xcb Also, the Python is only used to generate some generic C code. So if you want to stick with Xlib/XCB, just build xcb/proto and xcb/libxcb on some machine with newer Python and copy the generated C files over. Is the C platform-independent? Maybe we could add get it in dist? Just drop all the nodist_ from src/Makefile.am. I think that would be really nice to not require python while bootstrapping X. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does xcb really need python?
Twas brillig at 12:36:03 16.03.2009 UTC-07 when dbn.li...@gmail.com did gyre and gimble: DN Is the C platform-independent? Maybe we could add get it in dist? DN Just drop all the nodist_ from src/Makefile.am. I think that would DN be really nice to not require python while bootstrapping X. [points at commit 2e65188f91800d7e6a8d74fa077b46f8f67b6893] -- pgpzkdLCNSUaD.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
evdev broken
Hello, yesterday I upgraded my Debian Sid system a bit and to fulfill the dependencies also a more recent xserver-xorg-input-evdev package was installed. This causes some problems: 1) If I don't configure anything about keyboard and mouse in xorg.conf, I can't login anymore, since each keystroke will print the the character trice. 2) If I set the kbd driver as below in my xorg.conf, there are still issues left. E.g. ctrl+c will restart X. Section InputDevice Identifier keyboard Driver kdb Option XkbLayout de EndSection Present solution: Before starting X: rm -f /dev/input/event* Version: 1:2.1.1-1 Replaces: xserver-xorg ( 6.8.2-35) Provides: xserver-xorg-input-4 Depends: libc6 (= 2.7-1), xserver-xorg-core (= 2:1.5.99.901) Any ideas? Thanks, Bernd ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does xcb really need python?
2009/3/16 Mikhail Gusarov dotted...@dottedmag.net: Twas brillig at 12:36:03 16.03.2009 UTC-07 when dbn.li...@gmail.com did gyre and gimble: DN Is the C platform-independent? Maybe we could add get it in dist? DN Just drop all the nodist_ from src/Makefile.am. I think that would DN be really nice to not require python while bootstrapping X. [points at commit 2e65188f91800d7e6a8d74fa077b46f8f67b6893] That doesn't say whether it's platform-independent. It just says that it's autogenerated. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev broken
On Mon, Mar 16, 2009 at 09:25:42PM +0100, Bernd Schubert wrote: yesterday I upgraded my Debian Sid system a bit and to fulfill the dependencies also a more recent xserver-xorg-input-evdev package was installed. This causes some problems: 1) If I don't configure anything about keyboard and mouse in xorg.conf, I can't login anymore, since each keystroke will print the the character trice. do you have evdev devices configured in your xorg.conf? looks like the devices are picked up multiple times, most likely once through HAL, once through xorg.conf. 2) If I set the kbd driver as below in my xorg.conf, there are still issues left. E.g. ctrl+c will restart X. Do you have AllowEmptyInput set to false, yet an evdev device in the xorg.conf? There's a combination that didn't set raw mode on the tty, which got fixed in 1.5.99.903. Cherry-picking b33905234 should fix it. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: No fragment shader?
Roland Scheidegger wrote: On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland Thanks, Roland. That helped in that I found I had an old parallel install of googleearth installed that I cleaned out and I also found a newer 32-bit mesa (the machine is 64-bit). Unfortunately it still doesn't work. The googleearth screen comes up but when it tries to render the earth it crashes with this: Warning: Unable to create prefs directory '/home/markus/.googleearth'. File exists. libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) I tried setting the R300_SPAN_DISABLE_LOCKING var but it did the same thing (the R300_SPAN_DISABLE_LOCKING line in the console printout disappeared, otherwise the same). Anything else I can try? /Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: No fragment shader?
Markus Strobl wrote: Roland Scheidegger wrote: On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland Thanks, Roland. That helped in that I found I had an old parallel install of googleearth installed that I cleaned out and I also found a newer 32-bit mesa (the machine is 64-bit). Unfortunately it still doesn't work. The googleearth screen comes up but when it tries to render the earth it crashes with this: Warning: Unable to create prefs directory '/home/markus/.googleearth'. File exists. libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) I tried setting the R300_SPAN_DISABLE_LOCKING var but it did the same thing (the R300_SPAN_DISABLE_LOCKING line in the console printout disappeared, otherwise the same). Anything else I can try? /Markus In driconf, disable low-impact fallbacks. This will eliminate at least one of the error messages, and keep it from falling back to software rendering. ~ C. ___ 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-ati: No fragment shader?
Corbin Simpson wrote: Markus Strobl wrote: Roland Scheidegger wrote: On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland Thanks, Roland. That helped in that I found I had an old parallel install of googleearth installed that I cleaned out and I also found a newer 32-bit mesa (the machine is 64-bit). Unfortunately it still doesn't work. The googleearth screen comes up but when it tries to render the earth it crashes with this: Warning: Unable to create prefs directory '/home/markus/.googleearth'. File exists. libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) I tried setting the R300_SPAN_DISABLE_LOCKING var but it did the same thing (the R300_SPAN_DISABLE_LOCKING line in the console printout disappeared, otherwise the same). Anything else I can try? /Markus In driconf, disable low-impact fallbacks. This will eliminate at least one of the error messages, and keep it from falling back to software rendering. ~ C. Thanks. The warnings went away but it still crashes with this: libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 drmRadeonCmdBuffer: -22 (exiting) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Bug# 1382
Hi, I've stumbled across bug 1382 in my software dealing with the out of date motif header files that are used to construct the xorg-x11-6.8.2-1.EL.18 52 rpm's. These out of date headers are causing seg faults when attempting to use glwMDrawingAreaWidgetClass due to the size differences between the GL's PrimitiveP.h file and the one included with Motif2.2. I've noticed this still has not been resolved. Will a fix be added for a future release? Thank you, Dennis Quelch ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: No fragment shader?
Markus Strobl wrote: Corbin Simpson wrote: Markus Strobl wrote: Roland Scheidegger wrote: On 15.03.2009 19:18, Markus Strobl wrote: Just wondering if there's any work ongoing to fix the issue with googleearth where it exits with no fragment shader Using xf86-video-ati? It works fine with fglrx. Everything else works fine with xf86-video-ati: Composited desktop (KDE4 w/ effects), glxgears etc. Just googleearth refuses to work. Graphics are a R430 (ATI X800XL), xf86-video-ati-6.12, mesa-7.3. This is independent from xf86-video-ati. I suggest you try a newer mesa version (it looks to me like the error you quote there can only come from a pre-7.0 mesa version, in fact). Roland Thanks, Roland. That helped in that I found I had an old parallel install of googleearth installed that I cleaned out and I also found a newer 32-bit mesa (the machine is 64-bit). Unfortunately it still doesn't work. The googleearth screen comes up but when it tries to render the earth it crashes with this: Warning: Unable to create prefs directory '/home/markus/.googleearth'. File exists. libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) I tried setting the R300_SPAN_DISABLE_LOCKING var but it did the same thing (the R300_SPAN_DISABLE_LOCKING line in the console printout disappeared, otherwise the same). Anything else I can try? /Markus In driconf, disable low-impact fallbacks. This will eliminate at least one of the error messages, and keep it from falling back to software rendering. ~ C. Thanks. The warnings went away but it still crashes with this: libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x22 drmRadeonCmdBuffer: -22 (exiting) Also getting this in /var/log/messages: Mar 16 18:56:14 markuspc [drm:r300_do_cp_cmdbuf] *ERROR* r300_scratch failed ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug# 1382
Dennis Quelch wrote: Hi, I've stumbled across bug 1382 in my software dealing with the out of date motif header files that are used to construct the xorg-x11-6.8.2-1.EL.18 52 rpm's. These out of date headers are causing seg faults when attempting to use glwMDrawingAreaWidgetClass due to the size differences between the GL's PrimitiveP.h file and the one included with Motif2.2. I've noticed this still has not been resolved. Will a fix be added for a future release? Xorg 6.8.2 is a very out of date release, and is years behind what we're currently distributing (X11R7.4 is the most current release of the X Window System). As noted in that bug report, we can't find the files referenced in anything X.Org or Mesa is currently distributing, so it sounds like you need to ask your xorg-x11-* RPM provider when they will update to a newer release. (X.Org only releases the source files - RPM's and other package formats are put together by others.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug# 1382
2009/3/17 Alan Coopersmith alan.coopersm...@sun.com: Dennis Quelch wrote: I've stumbled across bug 1382 in my software dealing with the out of date motif header files that are used to construct the xorg-x11-6.8.2-1.EL.18 52 rpm's. These out of date headers are causing seg faults when attempting to use glwMDrawingAreaWidgetClass due to the size differences between the GL's PrimitiveP.h file and the one included with Motif2.2. I've noticed this still has not been resolved. Will a fix be added for a future release? Xorg 6.8.2 is a very out of date release, and is years behind what we're currently distributing (X11R7.4 is the most current release of the X Window System). As noted in that bug report, we can't find the files referenced in anything X.Org or Mesa is currently distributing, so it sounds like you need to ask your xorg-x11-* RPM provider when they will update to a newer release. (X.Org only releases the source files - RPM's and other package formats are put together by others.) Those look like Red Hat Enterprise - RHEL4 era, I think. Definitely one for paid distro support. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with KMS on drm-intel-next branch
On 2009.03.17 07:25:52 +0800, 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 That commit has drawbacks and needs rework. Could you attach bios_reader output? The utility is under xf86-video-intel/src/bios_reader, make sure you're on git tip or 2.7 branch. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xlib - reporting X errors [+patches]
I was going through old patch mail and see this never got handled - sorry about
that, we've not been good at always staying on top of our incoming patch queue.
I've pushed the first change to XGetErrorText() as is, and pushed the portions
of the XErrorDB patch that weren't already in git - thanks for those.I'm not
pushing the second XGetErrorText() patch as it seems redundant to the
if (!buffer[0] bext) {
case just above it - is there something I'm missing there?
I agree we need to think more about our error handlers and allowing replacements
to get the information out of Xlib that it already has - it might help avoid
things like the abomination that is the gtk error handler, which swallows up
useful information like which extension the error was hit in, just so it can
print a longer and more useless error message than the Xlib default one.
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
Lubos Lunak wrote:
Hello,
the simple part: XGetErrorText() has a bug that prevents it from finding
text
for errors which have error code equal to the error base for the extension
(such as BadRegion in XFixes). Attached patch ErrDes.c.patch fixes that.
Also, the errors file is missing some items, XErrorDB.patch adds those.
Please review and apply them.
The not so simple part: These fixes will take some time to be shipped with
distros, and even then, X error handlers still can't provide that useful
information. Imagine you're looking at a bugreport including a debug output
from an application saying something like X error: error code 185, request
159/2 - you have no idea what that actually is, without knowing opcodes and
error bases of all extensions (think large codebase, not some hello-word
application initializing all needed extensions in one place).
As a small help, I suggest also applying the ErrDes_2.c.patch file, that
makes XGetErrorText() print the error number at least with the extension
name, in case the error message is missing in XErrorDB again. There is
unfortunately no XGetRequestText() that would print request name for given
opcode, and XGetErrorDatabaseText() requires extension name passed.
But the problem is, it appears that one even cannot know the opcodes and
error bases for an error:
- Xlib knows those, but they are in internal structures
- using XListExtensions() and XQueryExtension() with the same X connection in
an X error handler is not allowed by XSetErrorHandler()
- doing the same, with another connection, completely locks up whole X when
the server is grabbed
- _XPrintDefaultError() would work nicely, but it is not exported
- the default X error handler, which calls _XPrintDefaultError(), calls
exit()
right after it
Does somebody see a way to handle this problem? Would it be possible to e.g.
add functions to Xlib to access the data in internal structures?
___
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: Dual screen on ATI 9600 | NV350 AQ using radeon driver - clone only ?
Dear Torbjørn, Maybe you can change the xorg.conf like this: Section Monitor Identifier VGA-0 Option PreferredMode 800x600 EndSection Section Monitor Identifier DVI-0 Option PreferredMode 800x600 Option RightOf VGA-0 EndSection If you don't want to specify the mode, the virtual size may be too small. You can change the virtual size like this, but you can't exceed the limitation of hardware. Section Screen DefaultDepth 24 SubSection Display Depth 24 Virtual 2560 2560 EndSubSection EndSection Please have a try, thanks! Best wishes, Gordon -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Torbj?rn Thorsen - Nextline Sent: 2009年3月16日 20:50 To: x...@freedesktop.org Subject: Dual screen on ATI 9600 | NV350 AQ using radeon driver - clone only ? I have to identical monitors running at 1280x1024. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm S-video disconnected (normal left inverted right x axis y axis) The first problem was the Virtual size was too small to fit two of both outputs, so that got configured in xorg.conf. Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2560 x 1024 So now I should be ready for running dual screen ? torbj...@torbjorn-desktop:~$ xrandr --dryrun --output DVI-0 --right-of VGA-0 screen 0: 2560x1024 675x270 mm 96.33dpi crtc 0:1280x1024 60.0 +1280+0 DVI-0 VGA-0 The result of doing this is that both outputs end up with the same offset, in effect, I can only see the right side of the virtual screen. torbj...@torbjorn-desktop:~$ xrandr | grep connected VGA-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm DVI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 338mm x 270mm I have tried lots of different ways to get them to show the whole virtual screen, including using --pos, but I can't get them to split. The outputs always see the same area of the virtual screen. If anybody could point me in the right direction, I would be very grateful. -- Torbjørn ___ 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
