multiple windows Xv application keep color only with 64bit os and not for 32bit
Hello,
I am trying to write a multiple windows Xv application but when there is
more than one window the image is put only onto one of them for 32bit ubuntu
8.04, while for 64bit ubuntu 8.04 the application works correctly and all
windows have their correct image content displayed. What could be the
problem? Here is the code, thanks in advance.
Makefile
all: testxv2
INCLUDES = -I ./ -I /usr/include/X11/
LINKLIBS = -lpthread -lX11 -lXext -lXv
SOURCES := $(wildcard *.cc)
OBJECTS := $(SOURCES:.cc=.o)
CFLAGS := -g
XVWindow.o: XVWindow.cc $(wildcard *.h)
g++ -c $ -o $@ $(INCLUDES) $(CFLAGS)
testxv2.o: testxv2.cc $(wildcard *.h)
g++ -c $ -o $@ $(INCLUDES) $(CFLAGS)
testxv2: Makefile $(OBJECTS) $(wildcard *.h)
g++ -o testxv2 $(OBJECTS) -L/usr/X11R6/lib $(LINKLIBS) $(CFLAGS)
clean:
rm -f *.o testxv2
---
XVWindow.cc
#include iostream
#include iomanip
#include unistd.h
#include stdint.h
#include Xatom.h
#include XVWindow.h
using namespace std;
XVWindowsContext xvc;
Bool waitForNotify( Display *, XEvent *e, char *arg )
{
return ( e-type == MapNotify ) ( e-xmap.window == (Window)arg );
}
XVWindow::XVWindow(int w, int h, char * thename)
{
pthread_mutex_lock(xvc.ctxMutex);
//pthread_cond_wait(xvc.ctxCond, xvc.ctxMutex);
XEvent event;
ImageBuffer = 0;
ImageWidth = WindowWidth = OldWindowWidth = w;
ImageHeight = WindowHeight = OldWindowHeight = h;
window = XCreateWindow( xvc.display,
RootWindow( xvc.display,
xvc.visualInfo.screen ),
0, 0, w, h, 0,
xvc.visualInfo.depth, InputOutput,
xvc.visualInfo.visual,
xvc.mask,
(xvc.xswa) );
strcpy(name, thename);
char * aname = (char*) malloc(256);
strcpy(aname, thename);
XTextProperty titleprop;
XStringListToTextProperty(aname, 1, titleprop);
XSetTextProperty(xvc.display, window, titleprop, XA_WM_NAME);
XFree(titleprop.value);
free(aname);
XMapWindow( xvc.display, window );
XIfEvent( xvc.display, event, waitForNotify, (char *)window );
gc = XCreateGC( xvc.display, window, 0L, xgcv );
pme = this;
xvc.WindowsArray[xvc.NumberOfWindows] = this;
xvc.NumberOfWindows++;
fullscreen = false;
CreateBGImage();
WindowAspectRatio = (float) ((float)ImageWidth)/((float)ImageHeight);
cout name ha aspect ratio WindowAspectRatio endl;
//pthread_cond_signal(xvc.ctxCond);
pthread_mutex_unlock(xvc.ctxMutex);
}
void XVWindow::ToggleFullScreen()
{
if(!fullscreen)
{
XMoveResizeWindow(xvc.display, window, 0, 0, xvc.DisplayWidth,
xvc.DisplayHeight);
XRaiseWindow(xvc.display, window);
XFlush(xvc.display);
WindowWidth = xvc.DisplayWidth; WindowHeight = xvc.DisplayHeight;
fullscreen = true;
return;
}
else
{
XMoveResizeWindow(xvc.display, window, 50, 50, ImageWidth,
ImageHeight);
XRaiseWindow(xvc.display, window);
XFlush(xvc.display);
WindowWidth = ImageWidth; WindowHeight = ImageHeight;
fullscreen = false;
}
}
XVWindow::~XVWindow()
{
DestroyBGImage();
XFreeGC( xvc.display, gc );
XDestroyWindow( xvc.display, window );
}
void XVWindow::SetWindowDimension(int w, int h)
{
OldWindowWidth = WindowWidth;
OldWindowHeight = WindowHeight;
WindowWidth = w;
WindowHeight = h;
}
void XVWindow::FixAspectRatioOfWindow()
{
//cout swd w= w h=hendl;
int deltax = 0, deltay = 0;
deltax = WindowWidth-OldWindowWidth; deltay =
WindowHeight-OldWindowHeight;
deltax = abs(deltax); deltay = abs(deltay);
cout dx= deltax dy= deltayendl;
if((deltax==0)(deltay==0)) return;
if(deltaxdeltay)
{
WindowHeight = (unsigned int)
(((float)WindowWidth)/WindowAspectRatio);
}
else
{
WindowWidth = (unsigned int)
(WindowAspectRatio*((float)WindowHeight));
}
cout new w dim WindowWidthxWindowHeightendl;
XWindowChanges xwc; xwc.width = WindowWidth; xwc.height = WindowHeight;
XConfigureWindow(xvc.display, window, CWWidth|CWHeight, xwc);
}
void RGBToUV(unsigned short int r,
unsigned short int g,
unsigned short int b,
unsigned short int * u,
unsigned short int * v)
{
*u = min(abs(r * -1214 + g * -2384 + b * 3598 + 4096 + 1048576) 13,
240);
*v = min(abs(r * 3598 + g * -3013 + b * -585 + 4096 + 1048576) 13,
240);
}
void RGBToY(unsigned short int r,
unsigned short int g,
unsigned short int b,
unsigned short int * y
)
{
*y = min(abs(r * 2104 + g * 4130 + b * 802 + 4096 + 131072) 13, 235);
}
void XVWindow::SetImagePixel(int x, int y, int r, int g, int b)
{
RE: [ANNOUNCE] xf86-video-intel 2.5.99.2
Giovanni Masucci wrote on Friday, January 16, 2009 11:20 AM: On venerdì 16 gennaio 2009 04:12:46 Jin, Gordon wrote: Sami Farin wrote on Friday, January 16, 2009 2:29 AM: On Tue, Jan 13, 2009 at 17:24:10 +0800, Jin, Gordon wrote: Tino Keitel wrote on Friday, January 09, 2009 3:45 AM: On Thu, Jan 08, 2009 at 16:04:55 +0800, Zhenyu Wang wrote: Subject: [ANNOUNCE] xf86-video-intel 2.5.99.2 I'd like to know how/what can/should be tested before the release. What versions of kernel/xserver/mesa/drm/whatever are required? And for what features (XvMC, UXA, DRI, DRI2, GEM, KMS, etc.), and what chips can use which features? Tino, Thanks for the question, and sorry for my late reply. In general, the release component info is maintained at http://intellinuxgraphics.org/download.html. So at that page you can find a recommended package (what we call 2008Q4 release, and it's -rc3 for now), with: xf86-video-intel: 2.6-branch. It's tagged as 2.5.99.2 for now. mesa: intel-2008-q4 branch. It's forked from master at some point (early Dec. 2008) and cherry-picked patches from master on demand, so a little more conservative than master. Of course master tip is supposed to work too, but not validated by Intel. libdrm: master branch. (note 2.4.2 is required for xf86-video-intel 2.6, and tip is recommended) kernel: Eric's drm-intel tree. For 2008Q4, we base on 2.6.28 kernel. So we are recommending drm-intel-2.6.28 branch, which adds 5 patches on top of 2.6.28. Can you put all the individual patches for 2.6.28 available at http://intellinuxgraphics.org/2008Q4.html ? Good suggestion. I'm putting the combination of the 6 patches with a link to 6 patches on that page. If I can ask, are these 6 patches going to enter the next 2.6.28.x releases or they'll just be in 2.6.29? These patches have been in 2.6.29-rc2. I don't know if they will enter 2.6.28.x. Eric may have the idea. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: save-under support
Patrick O'Donnell wrote: Date: Fri, 23 Jan 2009 01:44:24 + From: =?UTF-8?Q?Rui_Tiago_Ca=C3=A7=C3=A3o_Matos?= tiagoma...@gmail.com 2009/1/22 Patrick O'Donnell p...@ascent.com: I've been told, recently, that save-under and backing-store under 8-bit [visuals] are no longer supported in recent X.org releases. ... could someone point me to where I would find more authoritative information on the status of save-under and backing-store? http://cgit.freedesktop.org/xorg/xserver/commit/?id=ae7f71a8b3d6756161e55d998d6eec37d2695c98 I'm afraid that's as official as it gets. So, I take it that backing store (and from a commit last August, save under) is being flushed, not just for 8-bit visuals, but completely. The theory seems to be that compositing will do (almost) the same thing. (It's a shame that backing store = Always is being tossed to the wind. Apparently, backward compatibilty is given short shrift in favor of prettiness.) Now, I have two additional troubles. The problem we're seeing with our application -- our main chart window (with backing store) is being left blank under where a pop-up (with save-under) had been mapped -- occurs in X.Org servers that predate the commit you pointed me to. So, the removal of backing store, and the much later removal of save under don't seem to be the proximal problem. It has always been the case that a server may or may not honour requests for backing store and/or save unders. These features are intended as an optimisation; they do not eliminate the need to redraw portions of the window in response to Expose events. Even if the server does support backing store and/or save unders in general, whether or not it preserves contents in specific cases could depend upon factors such as the overall demand for video memory. IOW, if neglecting to handle Expose events has worked until now, then you just got lucky. If you want to perform rendering only at a time of your choosing, the simplest solution is probably to allocate a suitably-sized Pixmap, draw into that, and either: a) handle Expose events using XCopyArea(dpy, pixmap, window, ...), or b) use the Pixmap as the Window's background_pixmap (the server *may* make a copy of the Pixmap, so you should call XSetWindowBackgroundPixmap() whenever you modify its contents). Second, although, in my searching, I have found mention of Composite and compositing managers, I've yet to find a sufficiently detailed explanation of what compositing is doing and how it is invoked or configured for me to understand how I should be managing our application's windows to make use of it. Another pointer to a good reference would be appreciated. I don't know enough about compositing to answer this one. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: save-under support
Some time back I tried to use an old app -- which was available only as a binary -- with a modern server. The app's documentation explicitly noted that it required backing store and save under. Exactly as you saw, the windows of this app were blank. I discovered that it would work if there were no window manager running. As soon as a win mgr started, the app's windows would revert to a neutral gray. You might want to check whether that also happens for your apps. Just in case it helps the porting process -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
dri2+uxa, X restart after suspend/resume
Hi all, Here's another issue with DRI2/UXA on intel that I can't gather enough information about for a fruitful bug report. So, I'll ask the list if this issue is known. I'm on the latest released stack (libdrm 2.4.4, mesa 7.3, xserver 1.6rc, intel 2.6.1, kernel 2.6.28.1). With DRI2 and UXA enabled, the X server restarts after a suspend/resume cycle, and leaves me at the GDM login window. I can't find anything out of the ordinary in the logs. The last line of the log is (II) AIGLX: Suspending AIGLX clients for VT switch. I first thought it was related to the VT switching that's done before suspend, but that doesn't seem to be the case as switching VTs during a running session doesn't case any problem. Regards, Khashayar ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dri2+uxa, X restart after suspend/resume
On Sat, 24 Jan 2009, Khashayar Naderehvandi wrote: Hi all, Here's another issue with DRI2/UXA on intel that I can't gather enough information about for a fruitful bug report. So, I'll ask the list if this issue is known. I'm on the latest released stack (libdrm 2.4.4, mesa 7.3, xserver 1.6rc, intel 2.6.1, kernel 2.6.28.1). With DRI2 and UXA enabled, the X server restarts after a suspend/resume cycle, and leaves me at the GDM login window. I can't find anything out of the ordinary in the logs. The last line of the log is (II) AIGLX: Suspending AIGLX clients for VT switch. I first thought it was related to the VT switching that's done before suspend, but that doesn't seem to be the case as switching VTs during a running session doesn't case any problem. Same thing here.. care to file a bug on bugzilla.fd.o?-) t ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Pointer glide patch for Input/synaptics
Can you explain what reasonable defaults one should use for the friction? The default ones (I just applied the patch here) don't really make sense to me. If anything, they make the touchpad harder to use as there's a high chance that the pointer keeps moving after I have released over a button and I miss the target. Cheers, Peter Thanks for the thoughts, Peter! I agree, my defaults are sadly neglected. I'm hoping that over time some really good ones may emerge. There's a lot those two variables can do. (One recent realization that could help: the driver knows when a finger is a few mm away from the touchpad, so that could be used to apply some extra friction. Could also be total feature creep). Here is what I have now for configuration: PointerGlide= 1 PointerGlideFriction= 0.006 PointerGlideMaxSpeed= 5 ...Allowing some more flexibility. High max speed and high friction should get the slower moving pointers to stop nice and quickly so issues with pressing buttons are less of a problem. I have been pestering my friends and family with this for a little while now and they seem mostly positive about the idea, but I haven't had the chance to do much real-world testing except on myself. (And I am definitely not a real-world user). This has a nice effect for Fitt's law stuff. Fitt's law points to an idea that the user should be able to carelessly slam the mouse pointer to the top of the screen in order to press an important button like the main menu or the window switcher. The touchpad doesn't really allow this (maybe fancier pointer acceleration would help), but with my tweak the user can safely flick the pointer to a corner of the screen. As for justification, I think we have seen a very cohesive movement towards this type of interaction for touch screen interfaces. Kinetic scrolling is a must-have for any such thing. It's ultimately the same difference between kinetic scrolling and its predecessor as is moving the pointer with a touch pad, and even the same physical interface since both involve running one's finger on a touch-sensitive surface. I don't have ready proof that one method is superior to another. However, users consistently love kinetic scrolling because it lets them traverse long lists quickly, with the ability to stop on a dime and control scrolling speed naturally. They usually don't need to do repeat movements as we had with the classic push to scroll functionality, which is roughly equivalent to touch pads right now. Granted, it's difficult to aim at something in particular. This is usually overcome by having a predictable speed (and I think there may be a trick to the friction stuff that I don't quite have here). As for feature creep, I made sure to implement this whole thing inside of a single If statement, so the performance hit when PointerGlide=0 is similar to a fly impacting the Earth. I put it right below circular scrolling :P I agree, though, it's silly how much stuff is in the driver. I'm not an X person, but would extended input device data help? I guess that's usable for a higher level touchpad tweeking daemon, which would Hugely benefit by being closer to a specific desktop environment / user interface toolkit, and by being able to support different input devices that provide similar information. I believe this driver provides the relevant info through that path... right? Bye, -Dylan PS: One other little observation: I was originally running the Synaptics driver in Ubuntu's repositories (with some patches by Debian). I had an issue where the pointer would leap to a corner of the screen. I'd blamed it on my patch, but now I am running the driver from git and the problem is nonexistent. Does anyone by chance know if that behaviour was fixed in the last few months, or is this maybe a problem on Debian's end? signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
finding clock speed for intel chip
Hello, First I'd like to say thanks to everybody for your hard work. I have an intel gm45 igp (gma 4500MHD) - is there any way to find out the clock speed it's actually running at? I'm just curious.. Thanks in advance, Bogdan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: newest drivers lose X-video support?
On Fri, 23 Jan 2009, Tino Keitel wrote: On Fri, Jan 23, 2009 at 00:33:10 -0800, Brandon Kuczenski wrote: Hello, I recently installed updated versions of xserver-xorg-video-intel (2.5.1-1ubuntu5), libdrm2 and libdrm-intel1 (2.4.1-0ubuntu7) in order to try to resolve a suspend-to-RAM bug. I installed files from this archive: https://edge.launchpad.net/~intel-gfx-testing/+archive The fix appears to have worked, but an apparent side-effect is that I have lost X-video support. xvinfo returns: $ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present In the past, Ubuntu patched the Intel driver to disable textured video. If your hardware doesn't support video overlay anymore, you would end up without any XV adaptor at all. What hardware are you using? According to dmesg, it is an Intel Mobile GM45 on a brand-new Lenovo x200 laptop. I don't know much about what it supports- I only noticed because a formerly working app stopped working. Thanks for your time. -Brandon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dri2+uxa, X restart after suspend/resume
On Sat, Jan 24, 2009 at 8:37 PM, Timo Aaltonen tjaal...@cc.hut.fi wrote: On Sat, 24 Jan 2009, Khashayar Naderehvandi wrote: Hi all, Here's another issue with DRI2/UXA on intel that I can't gather enough information about for a fruitful bug report. So, I'll ask the list if this issue is known. I'm on the latest released stack (libdrm 2.4.4, mesa 7.3, xserver 1.6rc, intel 2.6.1, kernel 2.6.28.1). With DRI2 and UXA enabled, the X server restarts after a suspend/resume cycle, and leaves me at the GDM login window. I can't find anything out of the ordinary in the logs. The last line of the log is (II) AIGLX: Suspending AIGLX clients for VT switch. I first thought it was related to the VT switching that's done before suspend, but that doesn't seem to be the case as switching VTs during a running session doesn't case any problem. Same thing here.. care to file a bug on bugzilla.fd.o?-) t I'm a bit tied up in real life right now, but if no has beaten me to it, I'll file a bug as soon as I find the time. Problem is, though, I can't find any useful debugging information to go with the bug report. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Recent input changes
As it turns out, you're absolutely right. After rebuilding xserver with xnest disabled, evdev built fine. However, it looks like keyboard input severely regressed with these changes. For some reason modifiers are behaving very strangely. Ctrl-R and Ctrl-L for some reason functions as Caps Lock whereas Alt-L, Alt-R, and the Super keys do nothing at all. Despite this, xev seems to be receiving the correct keysyms: After Pressing Ctrl-L === KeyPress event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1155811, (536,187), root:(539,258), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1155959, (560,213), root:(563,284), state 0x3, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False === After Pressing Alt-L === KeyPress event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1208780, (214,389), root:(217,460), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1208896, (214,389), root:(217,460), state 0x3, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False === After Pressing Windows-L === KeyPress event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1208225, (214,389), root:(217,460), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x101, root 0x98, subw 0x0, time 1208358, (214,389), root:(217,460), state 0x5, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Besides the obvious issues, if one reads the above xev dump carefully, one will notice that the KeyPress event is reported as the Alt_L keysym whereas the KeyRelease event is reported as Meta_L. This struck me as a little strange. I can submit a bug or bisect if this will help. Thanks, - Ben On Sat, Jan 24, 2009 at 4:15 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Sat, Jan 24, 2009 at 12:47 PM, Ben Gamari bgam...@gmail.com wrote: Hey all, Recent xserver master has been failing to build. In particular, it looks like someone might have forgotten to commit a header file, Keyboard.c: In function 'xnestKeyboardProc': Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from incompatible pointer type Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts' Keyboard.c:178: warning: implicit declaration of function 'XkbInitKeyboardDeviceStruct' Keyboard.c:178: warning: nested extern declaration of 'XkbInitKeyboardDeviceStruct' Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from incompatible pointer type Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from incompatible pointer type Keyboard.c:122: warning: unused variable 'j' Keyboard.c:117: warning: unused variable 'modifier_keymap' Keyboard.c: In function 'xnestUpdateModifierState': Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state' Workaround with --disable-xnest for now. Daniel just tore a ton of crap out of XKB, and there are some things in bad shape. Moreover, it seems that evdev is also having issues, being unbuildable since Peter Hutterer's commit 1906e4d5 based on the patch he sent out on 19 Jan 2009 ([PATCH] Xi: define a default range of axis labels). Again, the patch he sent out includes the necessary changes to the include files so it seems that they just never made it into the commit: evdev.c: In function 'EvdevInitProperty': evdev.c:1745: error: 'AXIS_LABEL_PROP' undeclared (first use in this function) evdev.c:1745: error: (Each undeclared identifier is reported only once evdev.c:1745: error: for each function it appears in.) evdev.c:1751: error: 'AXIS_LABEL_PROP_REL_X' undeclared (first use in this function) evdev.c:1756: error: 'AXIS_LABEL_PROP_ABS_X' undeclared (first use in this function) evdev.c:1763: error: 'AXIS_LABEL_PROP_REL_Y' undeclared (first use in this function) evdev.c:1768: error: 'AXIS_LABEL_PROP_ABS_Y' undeclared (first use in this function) evdev.c:1775: error: 'AXIS_LABEL_PROP_ABS_PRESSURE' undeclared (first use in this function) Just figured I'd make sure this was known. Thanks,
Detaching usb mouse hangs X on intel 2.6.1
Folks- I'm running intel 2.6.1 driver (gentoo) on my thinkpad t61p. I generally use the laptop connected to an external monitor with external usb mouse/keyboard. Now when I unplug the usb hub that has the mouse and keyboard connected X hangs. The following is spit out on the terminal where I called startx from: (EE) Read error: No such device (19, -1 != 24) xinit: connection to X server lost. Let me know if any other info is needed. -matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
tv out w i915G
I'm struggling a bit to enable tv out on an Aopen i915Ga-HFS motherboard which has an integrated i915G. I've enabled tv output in the bios and get the boot screen on the svideo output (with some sync problems). First I'm trying to determine if tv out on this particular mobo is actually supported? I tried running startx without any config file, and no tv output seems to be detected; [r...@htpc drivers]# xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024 VGA disconnected (normal left inverted right x axis y axis) TMDS-1 disconnected (normal left inverted right x axis y axis) VGA-2 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x60060.3 640x48059.9 Since only the svideo cable is connected at this point, it appears that the driver labels the TV output as VGA-2? I'm using driver 2.3.2 which is what comes with fedora 9. Would 2.6.1 work better? I'm hesitating upgrading as it would require fedora 10. I was wondering if this board does TV output through SDVO, which is currently not supported except through a patch that exist in the git tree? I has a look at bug 9992, which seems to track sdvo tv output, but I couldn't find any reference to any sdvo tv output patch. log file; X.Org X Server 1.5.2 Release Date: 10 October 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-92.1.10.el5 i686 Current Operating System: Linux htpc 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 Build Date: 03 November 2008 12:34:56AM Build ID: xorg-x11-server 1.5.2-3.fc9 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Jan 25 13:08:45 2009 (EE) Unable to locate/open config file (II) Loader magic: 0x81ef400 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on linux (--) using VT number 8 (--) PCI:*(0...@0:2:0) Intel Corporation 82915G/GV/910GL Integrated Graphics Controller rev 4, Mem @ 0xd020/0, 0xc000/0, 0xd030/0, I/O @ 0xe400/0 (--) PCI: (0...@0:2:1) Intel Corporation 82915G Integrated Graphics Controller rev 4, Mem @ 0xd028/0 (==) Matched intel for the autoconfigured driver New driver is intel (==) Using default built-in configuration (30 lines) (==) --- Start of built-in configuration --- Section Device Identifier Builtin Default intel Device 0 Driver intel EndSection Section Screen Identifier Builtin Default intel Screen 0 Device Builtin Default intel Device 0 EndSection Section Device Identifier Builtin Default fbdev Device 0 Driver fbdev EndSection Section Screen Identifier Builtin Default fbdev Screen 0 Device Builtin Default fbdev Device 0 EndSection Section Device Identifier Builtin Default vesa Device 0 Driver vesa EndSection Section Screen Identifier Builtin Default vesa Screen 0 Device Builtin Default vesa Device 0 EndSection Section ServerLayout Identifier Builtin Default Layout Screen Builtin Default intel Screen 0 Screen Builtin Default fbdev Screen 0 Screen Builtin Default vesa Screen 0 EndSection (==) --- End of built-in configuration --- (==) ServerLayout Builtin Default Layout (**) |--Screen Builtin Default intel Screen 0 (0) (**) | |--Monitor default monitor (**) | |--Device Builtin Default intel Device 0 (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. (**) |--Screen Builtin Default fbdev Screen 0 (1) (**) | |--Monitor default monitor (**) | |--Device Builtin Default fbdev Device 0 ==) No monitor specified for screen Builtin Default fbdev Screen 0. Using a default monitor configuration. (**) |--Screen Builtin Default vesa Screen 0 (2) (**) | |--Monitor default monitor (**) | |--Device Builtin Default vesa Device 0 (==) No monitor specified for screen Builtin Default vesa Screen 0. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (==) FontPath set to:
Re: Pointer glide patch for Input/synaptics
On Thu, 2009-01-22 at 08:28 -0800, Dylan McCall wrote: Hello! I'm just wondering what people think of the little pointer glide thing I submitted. Here would be a better place for discussion than on bugzilla, if anyone is interested :) https://bugs.freedesktop.org/show_bug.cgi?id=19525 The mouse is a successful input technique because the physical device makes sense. It feels like the mouse pointer on the screen and obeys the laws of physics if someone throws it (not that anyone would do that). The important part is that the user controls the pointer directly snip This is all achieved through ridiculously primitive physics, of course! I have the pointer continuing along its path when the finger is released, slowed down gradually by a set friction and capped with a maximum speed to avoid anything weird happening. The pointer glide behaviour only gets in the way if one is expecting it, and defaults to being turned off. snip I really dislike touchpads so I won't comment on whether glide is an improvement or not. However, I do like real-time physics simulation code so here are a few thoughts: Restricting pointer_glide_friction to a positive value would ensure that the pointer can never move opposite the direction of the flick. Speed should never go negative. That would mean the pointer is moving in the opposite direction. There is no need to check if speed exceeds max_speed more than once since friction should damp speed until it reaches near-zero. Never test for equality with 0 when doing floating point math. Test the absolute value of the speed against a suitably-small constant (often called epsilon). The complex math can be avoided if you don't use speed and angle (polar coordinates) to store the velocity. Rectangular coordinate vector math is simpler for this task. Then instead of testing for non-zero speed you can do: if (fabs(velocity_x) epsilon || fabs(velocity_y) epsilon) /* still moving */ else /* stopped */ If hw-millis value overflows then the pointer could still move in the opposite direction -- though it would take a specific set of circumstances and may not be very noticeable. Cheers, -Matt Helsley ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
Hi, On Mon, Jan 05, 2009 at 06:55:50PM -0200, Tiago Vignatti wrote: Under KMS, we can build a feature to update the cursor directly to screen without the continuous intervention of the userspace application (X server, wayland, etc). It's a fastpath for DRM based cursors obtained by short-circuit the kernel input layer and DRM module. This would solve all cursor's latency issues that we have in our current model [0]. IHMO punting and pushing this into the kernel in totally the wrong approach. Following this method, you will end up running *everything* in kernel space. (Hi, DOS!) Rather, you should try to figure out *why* the update in user space has latencies not present when doing it in kernel space. Is it because all kernel memory is pinned? (Not true on all systems, BTW.) Is it because event delivery between kernel space and user space triggers bad CPU scheduling? Is it because the handling in user space is not properly prioritized? Once you know the real caus(es), you can go about fixing them -- adapting the design of the user space part, and possibly creating now kernel interfaces is necessary. Ultimately, the kernel/user space distinction is just an address space boundary. There is no fundamental reason why that should cause any latencies. -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: define a default range of axis labels.
On Fri, Jan 23, 2009 at 11:00:05PM -0800, Matt Helsley wrote: On Mon, 2009-01-19 at 23:23 +1100, Peter Hutterer wrote: ATM, we are able to announce that a device has multiple axes, but clients have to take educated guesses as to wether axis N is tilt, pressure, pan or bananas. This patch introduces a set of default properties, initialized by the server on init. Drivers can then take the AXIS_LABEL_PROP and fill it with the matching labels to indicate to the client which axis does what. Clients can query this property and adjust their user interface accordingly. The range of labels is taken from linux/input.h, presumably that's the ones at least the Linux kernel can give us for a device. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net [...] A nit: Rel and Abs may be abbreviations end-users wouldn't recognize. Perhaps expanding them would be good. Ideally, end users would never see these properties as they are abstracted through matching GUI interfaces that label these properties with the correct strings, matching the user's language etc. (one is allowed to hope). I expect developers to be able to figure out what Rel and Abs stands for, so while you're right that spelling it out may be more apropriate, I'm going to be lazy and let it be. :) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dri2+uxa, X restart after suspend/resume
On Sun, 25 Jan 2009, Khashayar Naderehvandi wrote: I'm a bit tied up in real life right now, but if no has beaten me to it, I'll file a bug as soon as I find the time. Problem is, though, I can't find any useful debugging information to go with the bug report. I've filed it as http://bugs.freedesktop.org/show_bug.cgi?id=19731 t ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
