Re: keysymdef.h has wrong implies symbol?
On Tue, Oct 14, 2008 at 02:16:22PM +0200, Erik Streb del Toro wrote:
When I have “implies”¹ in my xkbmap it produces not the expected
U+21D2 RIGHTWARDS DOUBLE ARROW
as described in the comment of keysymdef.h but the symbol
U+22A2 RIGHT TACK
But this only in KDE apps not in Gnome/GTK. But if I use the X input
method by typing
export GTK_IM_MODULE=xim
then all GTK apps produce the wrong symbol, too.
Could this be the fix? Applies to libX11.
(I don't claim that I know what I'm doing here).
diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c
index 83c1483..4b4f628 100644
--- a/src/xlibi18n/imKStoUCS.c
+++ b/src/xlibi18n/imKStoUCS.c
@@ -120,7 +120,7 @@ static unsigned short const keysym_to_unicode_8a4_8fe[] = {
0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, /*
0x08b0-0x08b7 */
0x, 0x, 0x, 0x, 0x2264, 0x2260, 0x2265, 0x222b, /*
0x08b8-0x08bf */
0x2234, 0x, 0x221e, 0x, 0x, 0x2207, 0x, 0x, /*
0x08c0-0x08c7 */
-0x2245, 0x2246, 0x, 0x, 0x, 0x, 0x22a2, 0x, /*
0x08c8-0x08cf */
+0x2245, 0x2246, 0x, 0x, 0x, 0x, 0x21d2, 0x, /*
0x08c8-0x08cf */
0x, 0x, 0x, 0x, 0x, 0x, 0x221a, 0x, /*
0x08d0-0x08d7 */
0x, 0x, 0x2282, 0x2283, 0x2229, 0x222a, 0x2227, 0x2228, /*
0x08d8-0x08df */
0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, /*
0x08e0-0x08e7 */
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
Amit wrote: Thank you all for your inputs. I built x-server with kdrive enabled as Mikhail and Kamalneet suggested. I used the Xorg 7.2 release. It did build up successfully but with so many extensions enabled [:(] which I'm not sure whether I will be using or not. So, now I'm trying to customize my build configuration and choose relevant extensions only i.e extensions which my GTK+ framework will depend upon or use. I have a couple of questions: 1. I found two packages on maemo repository namely Xorg and X-server. What is the difference between the two? I thought both are same. Additionally there is --enable-xorg configure option available while building Xorg-server. What is the usage of that. 2. Can someone please explain me the usage of: --disable-glx, --enable-xgl, --enable-xglx, --enable-xegl GLX extension adds OpenGL commands to the protocol. So X clients can use OpenGL. XGL is an X Server built *on top of* OpenGL. Xegl and Xglx are two flavors of XGL. To use XGL on desktop, you'll need --enable-xgl --enable-xglx. My motive is to enable OPEN GL ES backend for EGL on X. Which option do I have to use? By default it enables OPENGL backend while I need OPENGL ES extension. What do you want to do? 1. Enable X clients(applications) to use OpenGL ES + EGL? or 2. Make X Server itself use OpenGL ES + EGL for rendering? I don't know of any open source solution for (2). And it is a significant development effort. XGL uses OpenGL(through glitz). Few months back, XGL support was removed from the xserver master branch. ~kammal ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
Daniel Stone wrote: On Tue, Oct 14, 2008 at 08:40:13AM +0100, John Tapsell wrote: 2008/10/14 Amit [EMAIL PROTECTED]: Only building Xserver will be sufficient or do I have to build the whole X11 package availbale at http://xorg.freedesktop.org/releases/X11R7.2/src/ ? Why not just go for the full X11? Memory wise I found no difference in the memory usage between X11 and kdrive on the OMAP. Right, and future releases of Maemo will be using Xorg instead of KDrive, for exactly that reason. Thanks for the info. Will be nice if someone can quickly tell any pros and cons of using kdrive instead of Xorg, for embedded systems where we know the hardware at build time. Are there any performance differences between Xorg and kdrive? Is EXA better than KAA? The development effort of writing a new kdrive server (based on Xfbdev) vs writing Xorg driver for a new hardware? I guess kdrive is easier and cleaner, maybe because I'm not at all familiar with Xorg development. Thanks ~kammal Cheers, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel card with uxa enabled causes garbled screen
On Monday, October 13, 2008 10:45 am Hanno Böck wrote: Hi, My card is: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (laptop Lenovo T61) When trying to enable uxa (all relevant packages on git head), I get this: http://files.hboeck.de/intel/img_3367.jpg the log: http://files.hboeck.de/intel/Xorg.0.log.uxa This may be the cause(?): (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc008 to 0xd009 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): ESR is 0x0001 (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. No it looks like you're using UXA with tiling enabled. That's not supported at the moment. Really UXA won't be usable until the GTT mapping stuff I've been working on gets merged (still tracking a bug or two in it but I'm almost done other than that), since in order for it to handled tiled regions it needs to map them through a fence register, which is part of mapping it through the GTT. And in order to get decent performance for operations that use software fallbacks, it needs to map framebuffer memory through the GTT rather than mapping the backing store and doing a cache flush for every operation. Anyway, should be working soon... Jesse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nvidia and ATI in one System
Moritz Lutz schrieb: is it possible to show me you xorg.conf? Or are you using the Multiseat option on this system? I put into /etc/gdm/gdm.conf: 8 8 [servers] 0=Multi 1=Standard 2=Second # Also note, that if you redefine a [server-foo] section, then GDM will # use the definition in this file, not the GDM System Defaults configuration # file. It is currently not possible to disable a [server-foo] section # defined in the GDM System Defaults configuration file. # [server-Multi] name=Dummy server command=/usr/bin/X -config xorg-X.conf -layout Multi -audit 0 vt7 flexible=false handled=false [server-Standard] name=Standard server command=/usr/bin/X0 -config xorg-X0.conf -layout X0 -audit 0 vt7 -noreset -sharevts -novtswitch flexible=false [server-Second] name=Second server command=/usr/bin/X1 -config xorg-X2.conf -layout X2 -audit 0 vt7 -noreset -sharevts -novtswitch flexible=false 8 8 The respective xorg-X*.conf files are attached. My cards according to the Xorg*log are nVidia Corporation NV34 [GeForce FX 5200] rev 161 (AGP) and ATI Technologies Inc unknown chipset (0x94cc) rev 0 Chipset: ATI RV610 (that is ATI Radeon HD 2400 PowerColor PCI with internal PCIe-to-PCI bridge). Regards and enjoy :-) Alexander. # xorg.conf (xorg X Window System server configuration file) # # # Dummy # Section ServerLayout Identifier Multi Screen DummyScreen InputDevice Dummy Keyboard InputDevice Dummy Mouse EndSection Section Screen Identifier DummyScreen Device Dummy MonitorStandardbildschirm DefaultColorDepth 8 SubSection Display Modes 320x240 EndSubSection EndSection Section Device Identifier Dummy Driver dummy VideoRam75 EndSection Section InputDevice Identifier Dummy Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout de Option XkbVariantnodeadkeys EndSection Section InputDevice Identifier Dummy Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection # # EOF # xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section ServerFlags Option AllowMouseOpenFailtrue Option HandleSpecialKeys Always Option DontVTSwitch EndSection Section InputDevice Identifier Generic Keyboard # Change the value of the Dev Phys option to the physical # address of the corresponding keyboard, found in the file # /proc/bus/input/devices . Driver evdev Option Device /dev/input/by-path/platform-i8042-serio-1-event-kbd # Configure your keyboard as usual Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout de Option XkbVariantnodeadkeys EndSection Section InputDevice Identifier Configured Mouse # Change the value of the Dev Phys option to the physical # address of the corresponding mouse, found in the file # /proc/bus/input/devices . Driver evdev Option Device /dev/input/by-path/pci-:00:02.1-usb-0:2:1.0-event-mouse # All mice should have CorePointer Option CorePointer Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Device Identifier Standardgrafikkarte # Driver nvidia Driver nv BusID PCI:3:0:0 EndSection Section Monitor Identifier Standardbildschirm Option DPMS HorizSync 28-84 VertRefresh 43-60 EndSection Section Screen Identifier Default Screen Device Standardgrafikkarte
Re: Nvidia and ATI in one System
Moritz Lutz schrieb: Or are you using the Multiseat option on this system? Please, what do mean by Multiseat option? Regards, Alexander. smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nvidia and ATI in one System
You answered all my questions with the previous post! :). Thanks a lot. Greetings Moritz On Wed, Oct 15, 2008 at 3:57 PM, Mader, Alexander (N-MSR) [EMAIL PROTECTED] wrote: Moritz Lutz schrieb: Or are you using the Multiseat option on this system? Please, what do mean by Multiseat option? Regards, Alexander. ___ 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: Embedded X
uClibc is in heavy development. perhaps you can forward your problems building with uClib to the uClib Mailinglist ? IMHO the lack of I18N (i do not know the state of uClib here either!) is not a problem since it is designed for memorytight systems where it is unlikly to have i18n at all. re, wh Jim Gettys schrieb: Does uClibc actually buy you anything? Last I looked, (admittedly quite a few years ago), it lacked I18N support that most products now require, at least by the time you are doing serious UI work. But times may have changed, and it isn't obvious from the sketchy documentation. At that date, we ended up having to carry glibc anyway, at which point it is moot, and uClibc just ended up costing space, rather than saving it. - Jim On Tue, 2008-10-14 at 09:22 -0700, William Tracy wrote: On Tue, Oct 14, 2008 at 12:40 AM, John Tapsell [EMAIL PROTECTED] wrote: Why not just go for the full X11? Memory wise I found no difference in the memory usage between X11 and kdrive on the OMAP. I am told that the full Xorg isn't very happy when built against uClibc. The original poster probably isn't using uClibc, but can anyone comment on building the full server against uClibc? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nvidia and ATI in one System
Thanks Alexander, is it possible to show me you xorg.conf? Or are you using the Multiseat option on this system? greetings Moritz On Wed, Oct 15, 2008 at 2:52 PM, Mader, Alexander (N-MSR) [EMAIL PROTECTED] wrote: Moritz Lutz schrieb: i got a general Question. I got a nvidia onboard graphic card and a ATI X1550 (PCI) with dual dvi in my System and i want to use both cards. Is this possible? Hello, yes, it is, and not just in principle: I am running a (quite old) system with nVidia AGP and ATI PCI card using the open source drivers since May this year. In my setup the closed source drivers cause trouble as I had to confirm the day before yesterday when I tried the 173.14.09 driver as it is shipped with Debian testing and got a frozen system. The last fglrx test is a bit older and resulted in slow 2D. I want to use a vga Monitor on the nvidia, and two dvi monitors on the ATI. Because during my tests i got no success, i got it working that all 3 Screens got black but then the hole System was freeze ( it was opensuse 11.0 ). I was able to cope with black screens and freezes by using a dummy X server for initialization as mentioned for instance here[1]. Obviously, it didn't help with my latest closed source nVidea test, see above. So, perhaps it is unnecessary. I assume you want to use Xinerama with the double head ATI card. I have no idea about this. Regards and enjoy :-) Alexander. [1]https://help.ubuntu.com/community/MultiseatX ___ 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: Embedded X
On Oct 15, 08 14:25:07 +0530, Amit wrote: I want my applications to use OPENGL ES + EGL. So I think I have to go with --enable-xgl --enable-xglx. No, you need --enable-glx. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transfer display of active windows remotely
This transfer of display is already implemented in the GTK tookit, though there are serious loose ends. There is a teleport application to signal a window to migrate. The loose ends are: o last I looked, while the window got moved, the toolkit retained an open connection to the original server. This was due to Xlib shortcomings, where to hack in support to handle errors properly would have been a pain. With Xcb now is the time to finish this up. o authentication is an issue. You want to ensure that windows can't easily be grabbed; but more importantly, you want casual use of displays to be possible, so prior use of ssh is pretty heavyweight. Ideally, some work with a library like cyrus sasl might be useful to make migration really practical. - Jim On Sat, 2008-10-11 at 03:27 -0700, Prasad H.L. wrote: This is what I have in mind. - Consider display :0 on machine 1 (m1) and display :0 on machine 2 (m2). - Let us say, a process 'p1' running under privileges of user 'u' opens a window on :0 of m1. - I do an 'ssh -X [EMAIL PROTECTED]' in xterm on :0 of m2 and login to m1. - Now, from that xterm window, is there any way by which I can make that window of process 'p1' appear on :0 of m2. This kind of situation regularly occurs to me and some of my friends. We have multiple terminals at our disposal. On one terminal, I start some xterm which is, let us say, showing output of some process. I go to some other department in the institute and do an ssh to that terminal. Now, I have no way of seeing what is going on in that xterm. Well, this is a simple example, of course. Another example (though childish). Consider a case where I have a browser window with many tabs open in it, the window being displayed on :0 of m1. I would like to export it to :0 of m2 when I go and sit in front of m2. Before closing ssh on m2, I re-export the window back to :0 of m1 and then quit the ssh. Such a feature would be really great to have. Since, any way, currently the only dependency on the remote machine is that it should have an X server running, I believe this feature should be implementable if not already present. With Regards, Prasad H. L. --- On Sat, 10/11/08, Pat Kane [EMAIL PROTECTED] wrote: Prasad, Your question is very interesting, could you draw a picture for me of what you want to do? Pat --- On Fri, Oct 10, 2008 at 11:50 PM, Prasad H.L. [EMAIL PROTECTED] wrote: I am active user of X.org and I admire the power and features that X.org provides to the users. I regularly use exported display over an ssh session and operate. I commend the developers for such a wonder piece of software. However, I would like to know one thing as described below. Consider a case where a window has been opened on the local terminal with some user id. After performing a remote login to and exporting the display to that machine using the same user id, is there any way by which the display of that opened window can be transferred to the remote exported display and vice versa? If not possible, then please consider this as a feature request. With Regards, Prasad H. L. --- Prasad H. L. PhD Student (with Dr. Shalabh Bhatnagar), Department of Computer Science and Automation, Indian Institute of Science, Bangalore - 560012 ___ 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 -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
Hi Michel, Thanks a lot for your investigation. Does the attached xserver patch help? Looks like we're syncing unnecessarily in the migration no-op case. Yes, a lot. My benchmark went up from ~12fps to ~19fps and the fallback is gone according to the profile. I am still only at 50% of intel-2.1.1/xorg-server-1.3's throughput, however a lot of time is spent inside the intel-driver - I guess its related to the refactoring to make it GEM ready. Thanks again, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Heads up
Kristian Høgsberg wrote: Hi, Here's a quick, last-minute note on the state of DRI2 before I take off for 2 weeks of vacation. I just pushed the updated protocol+docs to dri2proto and updated mesa, xserver and the dri2 branch of xf86-video-intel with the corresponding changes. What's implemented here is the lowest level of support that we've discussed: none vsync handling or page-flipping idea we've discussed are there yet. What is in place is the basic DRI2CopyRegion request, and more importantly, the mechanism for adding further args and return values to that request in later DRI2 revisions. I think we can merge the dri2 branch to master in xf86-video-intel now, since it still requires an Option DRI2 in xorg.conf to enable and the APIs and protocol feels like they're in place at this point. But since I don't expect to be back online and help with merging issues until November, I can understand if we want to hold off on that. Either way, please have a look and hopefully we can sort this out next month at least. \o/ this is why I love intel gfx. The real innovation seems to be coming from this camp even if some of the other manuf. have more powerful chips etc. Good work. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: keysymdef.h has wrong implies symbol?
Peter Hutterer schrieb am 15.10.2008 08:02: On Tue, Oct 14, 2008 at 02:16:22PM +0200, Erik Streb del Toro wrote: When I have “implies”¹ in my xkbmap it produces not the expected U+21D2 RIGHTWARDS DOUBLE ARROW as described in the comment of keysymdef.h but the symbol U+22A2 RIGHT TACK Could this be the fix? Applies to libX11. (I don't claim that I know what I'm doing here). diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c Yes, I think that this is the fix. But does somebody know, if the comment in the file http://cgit.freedesktop.org/xorg/proto/x11proto/tree/keysymdef.h lines 107–114 are still important? These are the files: http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c and http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/specs/XProtocol/X11.keysyms I couldn’t find any problems in these files. In the X11.keysyms are just some comments, which are correct regarding the buggy implies symbol in the file imKStoUCS.c. In the other file, KeyBind.c, is nothing interfering with this bug, as far as I can see. Can someone please verify that and then commit the patch proposed by Peter Hutterer? Greets Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: [EMAIL PROTECTED] Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
What do you want to do? 1. Enable X clients(applications) to use OpenGL ES + EGL? or 2. Make X Server itself use OpenGL ES + EGL for rendering? I want my applications to use OPENGL ES + EGL. So I think I have to go with --enable-xgl --enable-xglx. Regards Amit ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
Are there any performance differences between Xorg and kdrive? Is EXA better than KAA? My tests with the very lastest OMAP boards: I found a 20% speed improvement on the OMAP between kdrive fbdev KAA and xorg fbdev EXA. However I didn't not use the most recent version of kdrive for the comparision, so I don't know what the difference is now. I found no memory usage difference between the newest kdrive and newest Xorg. The development effort of writing a new kdrive server (based on Xfbdev) vs writing Xorg driver for a new hardware? I guess kdrive is easier and cleaner, maybe because I'm not at all familiar with Xorg development. It is a harder to get started with Xorg because there's quite a bit of code that you need to get started. However writing the Xorg driver is much cleaner. It is a separate driver, and can be compiled etc completely independently of Xorg. For KDrive, however, it's much more 'built-in'. Also there are things you can do with an Xorg driver that you can't do with kdrive. For example manage your own pixmap memory - essential if you have a UMA system (unified memory). So basically I would join the chorus here in recommending to go with Xorg John ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nvidia and ATI in one System
Moritz Lutz schrieb: i got a general Question. I got a nvidia onboard graphic card and a ATI X1550 (PCI) with dual dvi in my System and i want to use both cards. Is this possible? Hello, yes, it is, and not just in principle: I am running a (quite old) system with nVidia AGP and ATI PCI card using the open source drivers since May this year. In my setup the closed source drivers cause trouble as I had to confirm the day before yesterday when I tried the 173.14.09 driver as it is shipped with Debian testing and got a frozen system. The last fglrx test is a bit older and resulted in slow 2D. I want to use a vga Monitor on the nvidia, and two dvi monitors on the ATI. Because during my tests i got no success, i got it working that all 3 Screens got black but then the hole System was freeze ( it was opensuse 11.0 ). I was able to cope with black screens and freezes by using a dummy X server for initialization as mentioned for instance here[1]. Obviously, it didn't help with my latest closed source nVidea test, see above. So, perhaps it is unnecessary. I assume you want to use Xinerama with the double head ATI card. I have no idea about this. Regards and enjoy :-) Alexander. [1]https://help.ubuntu.com/community/MultiseatX smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
Hi Aaron,
Please, I don't want to be rude or something here but how can we
argument that these functions above are _used_ by the sample server if
none of its open drivers use it? This is questionable.
Aaron Plattner escreveu:
hw/xfree86/common/xf86.h |4 +
hw/xfree86/common/xf86Events.c | 84
+++--
hw/xfree86/loader/xf86sym.c|2
3 files changed, 62 insertions(+), 28 deletions(-)
New commits:
commit 3fc4f40b6c6cb416c9dc4bdb35c91b4f32c03ccc
Author: Aaron Plattner [EMAIL PROTECTED]
Date: Sun Oct 12 16:08:26 2008 -0700
Restore xf86{Enable, Disable}GeneralHandler.
These were useful as part of the generic handler ABI, and are used by the
NVIDIA
driver.
This reverts part of commit 50081d2dfb79878cb931a15c265f0d60698dfd39.
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 84ea633..fbbfc73 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -195,6 +195,8 @@ void xf86DisableInputHandler(pointer handler);
void xf86EnableInputHandler(pointer handler);
pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer data);
int xf86RemoveGeneralHandler(pointer handler);
+void xf86DisableGeneralHandler(pointer handler);
+void xf86EnableGeneralHandler(pointer handler);
void xf86InterceptSignals(int *signo);
void xf86InterceptSigIll(void (*sigillhandler)(void));
Bool xf86EnableVTSwitch(Bool new);
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index e91b332..babe45b 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -743,6 +743,20 @@ xf86DisableInputHandler(pointer handler)
}
_X_EXPORT void
+xf86DisableGeneralHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+ return;
+
+ih = handler;
+ih-enabled = FALSE;
+if (ih-fd = 0)
+ RemoveGeneralSocket(ih-fd);
+}
+
+_X_EXPORT void
xf86EnableInputHandler(pointer handler)
{
IHPtr ih;
@@ -756,6 +770,20 @@ xf86EnableInputHandler(pointer handler)
AddEnabledDevice(ih-fd);
}
+_X_EXPORT void
+xf86EnableGeneralHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+ return;
+
+ih = handler;
+ih-enabled = TRUE;
+if (ih-fd = 0)
+ AddGeneralSocket(ih-fd);
+}
+
/*
* As used currently by the DRI, the return value is ignored.
*/
commit 2217d22a76cdb2460f9683a6bf74c7248612889d
Author: Aaron Plattner [EMAIL PROTECTED]
Date: Sun Oct 12 16:07:24 2008 -0700
Revert xfree86: xf86{Enable, Disable}InputHandler can be static.
These were potentially useful as part of the input handler ABI, even if
nobody
currently uses them.
This reverts commit 278c11f01fbc6d6bd91c5a7127928c9ef5d29fca.
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 0956f9c..84ea633 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -191,6 +191,8 @@ xf86SetDGAModeProc xf86SetDGAMode;
void SetTimeSinceLastInputEvent(void);
pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data);
int xf86RemoveInputHandler(pointer handler);
+void xf86DisableInputHandler(pointer handler);
+void xf86EnableInputHandler(pointer handler);
pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer data);
int xf86RemoveGeneralHandler(pointer handler);
void xf86InterceptSignals(int *signo);
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index a2c206e..e91b332 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -462,34 +462,6 @@ xf86ReleaseKeys(DeviceIntPtr pDev)
}
}
-static void
-xf86EnableInputHandler(pointer handler)
-{
-IHPtr ih;
-
-if (!handler)
- return;
-
-ih = handler;
-ih-enabled = TRUE;
-if (ih-fd = 0)
- AddEnabledDevice(ih-fd);
-}
-
-static void
-xf86DisableInputHandler(pointer handler)
-{
-IHPtr ih;
-
-if (!handler)
- return;
-
-ih = handler;
-ih-enabled = FALSE;
-if (ih-fd = 0)
- RemoveEnabledDevice(ih-fd);
-}
-
/*
* xf86VTSwitch --
* Handle requests for switching the vt.
@@ -756,6 +728,34 @@ xf86RemoveGeneralHandler(pointer handler)
return fd;
}
+_X_EXPORT void
+xf86DisableInputHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+ return;
+
+ih = handler;
+ih-enabled = FALSE;
+if (ih-fd = 0)
+ RemoveEnabledDevice(ih-fd);
+}
+
+_X_EXPORT void
+xf86EnableInputHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+ return;
+
+ih = handler;
+ih-enabled = TRUE;
+if (ih-fd = 0)
+ AddEnabledDevice(ih-fd);
+}
+
/*
* As used currently by the DRI, the return value is ignored.
*/
diff --git a/hw/xfree86/loader/xf86sym.c b/hw/xfree86/loader/xf86sym.c
index d0e8558..4891be2 100644
---
Re: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Tue, 2008-10-14 at 16:49 +0200, Maarten Maathuis wrote: On Tue, Oct 14, 2008 at 4:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Hello, I've a use-case where the client uploads 32x32 A8 images to an 256x256x8 pixmap which is later used as mask in a composition operation. The test-case is able to render with 40fps on xserver-1.3/intel-2.1.1 however with the latest GIT of both I only get ~10-15fps. Unfourtunatly I've not been able to create a stand-alone testcase which triggers this problem :-/ Using sysprof I can see a lot of time is spent moving data arround, very strange is that PutImage seems to cause a readback: ProcPutImage-ExaCheckPutImage-exaPrepareAccessReg-exaDoMigration-exaDoMoveOutPixmap-exaCopyDirty-exaWaitSync-I830EXASync In Composite I see the re-uploading again. Any idea why ProcPutImage could to fallback (there's plenty of free vram)? Are there tools / settings which could help me to identify the problem? Thank you in advance, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I think this is because intel does not provide an UploadToScreen hook (because it has no vram). It hasn't made (visible) effort to reintegrate UXA in EXA, because you can obviously be bit smarter than what is currently being done. I've got an idea or two on how to improve this, but intel should be more than capable in dealing with this. Migrating out for a write-only operation is just broken, and is the thing that should be fixed there. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] 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: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt [EMAIL PROTECTED] wrote:
On Tue, 2008-10-14 at 16:49 +0200, Maarten Maathuis wrote:
On Tue, Oct 14, 2008 at 4:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hello,
I've a use-case where the client uploads 32x32 A8 images to an
256x256x8 pixmap which is later used as mask in a composition
operation.
The test-case is able to render with 40fps on xserver-1.3/intel-2.1.1
however with the latest GIT of both I only get ~10-15fps.
Unfourtunatly I've not been able to create a stand-alone testcase
which triggers this problem :-/
Using sysprof I can see a lot of time is spent moving data arround,
very strange is that PutImage seems to cause a readback:
ProcPutImage-ExaCheckPutImage-exaPrepareAccessReg-exaDoMigration-exaDoMoveOutPixmap-exaCopyDirty-exaWaitSync-I830EXASync
In Composite I see the re-uploading again.
Any idea why ProcPutImage could to fallback (there's plenty of free vram)?
Are there tools / settings which could help me to identify the problem?
Thank you in advance, Clemens
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I think this is because intel does not provide an UploadToScreen hook
(because it has no vram). It hasn't made (visible) effort to
reintegrate UXA in EXA, because you can obviously be bit smarter than
what is currently being done. I've got an idea or two on how to
improve this, but intel should be more than capable in dealing with
this.
Migrating out for a write-only operation is just broken, and is the
thing that should be fixed there.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
I'd like to add that if anything changes in this beheaviour, then this
shouldn't be done quietly. Because some may depend on this (offscreen
memory tiled and needing migration to have something linear available
for example). The current {Prepare,Finish}Access isn't completely
suited for this conversion (exaPixmapIsOffscreen() isn't exported).
Just my 3 cent.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: patch: use Xrecord extension in syndaemon to avoid polling
On Mon, Oct 13, 2008 at 04:35:37PM +0200, Andre Herms wrote: Attached is a patch for the syndaemon of the synaptics driver. It prevents the polling of the keyboard state. Instead it uses the XRecord extension of the Xserver for an event triggered notification of key events. Of course, there is a fallback to the polling when no XRecord extension is found. This should finally stop complains of syndaemon preventing good power saving. Comments are welcome. Thanks for the patch! There's a number of irrelevant white-space changes in that patch. Can you please clean it up and re-send it? Thanks. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
On Wed, Oct 15, 2008 at 04:38:03PM -0300, Tiago Vignatti wrote:
Hi Aaron,
Please, I don't want to be rude or something here but how can we argument
that these functions above are _used_ by the sample server if none of its
open drivers use it? This is questionable.
Hi Tiago,
The fact that the NVIDIA driver uses these functions is pretty much
irrelevant here: the functions are a useful part of the input/general
handler API. Removing useful API entry points just because no driver
happens to use them *today* is a bad idea because it prevents modules that
would like to use them in the future from working with current servers.
As for the NVIDIA driver, you can use nm -D on it to see which symbols it's
linked against. Also, I have a list of the strings we pass to LoaderSymbol
at http://people.freedesktop.org/~aplattner/loadersymbol
It was a bit out of date, so I updated it.
-- Aaron
Aaron Plattner escreveu:
hw/xfree86/common/xf86.h |4 +
hw/xfree86/common/xf86Events.c | 84
+++--
hw/xfree86/loader/xf86sym.c|2 3 files changed, 62 insertions(+),
28 deletions(-)
New commits:
commit 3fc4f40b6c6cb416c9dc4bdb35c91b4f32c03ccc
Author: Aaron Plattner [EMAIL PROTECTED]
Date: Sun Oct 12 16:08:26 2008 -0700
Restore xf86{Enable, Disable}GeneralHandler.
These were useful as part of the generic handler ABI, and are used
by the NVIDIA
driver.
This reverts part of commit
50081d2dfb79878cb931a15c265f0d60698dfd39.
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 84ea633..fbbfc73 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -195,6 +195,8 @@ void xf86DisableInputHandler(pointer handler);
void xf86EnableInputHandler(pointer handler);
pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer
data);
int xf86RemoveGeneralHandler(pointer handler);
+void xf86DisableGeneralHandler(pointer handler);
+void xf86EnableGeneralHandler(pointer handler);
void xf86InterceptSignals(int *signo);
void xf86InterceptSigIll(void (*sigillhandler)(void));
Bool xf86EnableVTSwitch(Bool new);
diff --git a/hw/xfree86/common/xf86Events.c
b/hw/xfree86/common/xf86Events.c
index e91b332..babe45b 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -743,6 +743,20 @@ xf86DisableInputHandler(pointer handler)
}
_X_EXPORT void
+xf86DisableGeneralHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+return;
+
+ih = handler;
+ih-enabled = FALSE;
+if (ih-fd = 0)
+RemoveGeneralSocket(ih-fd);
+}
+
+_X_EXPORT void
xf86EnableInputHandler(pointer handler)
{
IHPtr ih;
@@ -756,6 +770,20 @@ xf86EnableInputHandler(pointer handler)
AddEnabledDevice(ih-fd);
}
+_X_EXPORT void
+xf86EnableGeneralHandler(pointer handler)
+{
+IHPtr ih;
+
+if (!handler)
+return;
+
+ih = handler;
+ih-enabled = TRUE;
+if (ih-fd = 0)
+AddGeneralSocket(ih-fd);
+}
+
/*
* As used currently by the DRI, the return value is ignored.
*/
commit 2217d22a76cdb2460f9683a6bf74c7248612889d
Author: Aaron Plattner [EMAIL PROTECTED]
Date: Sun Oct 12 16:07:24 2008 -0700
Revert xfree86: xf86{Enable, Disable}InputHandler can be static.
These were potentially useful as part of the input handler ABI,
even if nobody
currently uses them.
This reverts commit 278c11f01fbc6d6bd91c5a7127928c9ef5d29fca.
diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 0956f9c..84ea633 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -191,6 +191,8 @@ xf86SetDGAModeProc xf86SetDGAMode;
void SetTimeSinceLastInputEvent(void);
pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data);
int xf86RemoveInputHandler(pointer handler);
+void xf86DisableInputHandler(pointer handler);
+void xf86EnableInputHandler(pointer handler);
pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer
data);
int xf86RemoveGeneralHandler(pointer handler);
void xf86InterceptSignals(int *signo);
diff --git a/hw/xfree86/common/xf86Events.c
b/hw/xfree86/common/xf86Events.c
index a2c206e..e91b332 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -462,34 +462,6 @@ xf86ReleaseKeys(DeviceIntPtr pDev)
}
}
-static void
-xf86EnableInputHandler(pointer handler)
-{
-IHPtr ih;
-
-if (!handler)
-return;
-
-ih = handler;
-ih-enabled = TRUE;
-if (ih-fd = 0)
-AddEnabledDevice(ih-fd);
-}
-
-static void
-xf86DisableInputHandler(pointer handler)
-{
-IHPtr ih;
-
-if (!handler)
-return;
-
-ih = handler;
-ih-enabled = FALSE;
-if (ih-fd = 0)
-RemoveEnabledDevice(ih-fd);
-}
-
/*
* xf86VTSwitch --
* Handle requests for switching the vt.
@@ -756,6 +728,34 @@
Re: xserver: Branch 'master' - 2 commits
Aaron Plattner escreveu: As for the NVIDIA driver, you can use nm -D on it to see which symbols it's linked against. Also, I have a list of the strings we pass to LoaderSymbol at http://people.freedesktop.org/~aplattner/loadersymbol It was a bit out of date, so I updated it. disassemble the proprietary driver would not be illegal? -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
