Re: [PULL] input fixes for server-1.5-branch
Le 25/11/2008 02:09, Peter Hutterer a écrit : > Ajax, > > Please pull a few input fixes for server-1.5-branch: What about this patch from you? We've had it in our branch for a while and it helped quite a few users. http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.0-force-SwitchCoreKeyboard-for-evdev.patch?view=markup Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dinamically switch between Xinerama and Multiseat
On Monday 24 November 2008 16:29:12 Tobias Kaminsky wrote: > Hello, > > I have 2 TFTs with each 1280x1024. > Normally I work alone on the pc -> Xinerama. > But sometimes my girlfriend wants to work on the pc, too. But I do not want > to log out, change KDM and log in again. > > So I need something that works on the fly. > > Here is what I have this far: > > 1) Starting X across both TFTs. > 2) DISPLAY=:0 Xephyr :1 -br +xinerama -screen 2560x1024 > This lets me have one big screen where I can load KDM. > 3) DISPLAY=:1 xrandr -s 1280x1024 lets me change the size to one TFT. > > 3.1) Starting another Xephyr on the other TFT with a small Window Manager > is no big deal. > > Two Xephyr, one one each TFT > > Now "backwards": > Closing one Xephyr. > > 4) DISPLAY=:1 xrandr -s 2560x1024 > Not a supported mode any longer. > > This is my problem. Starting Xephyr with 2560x1024 works fine. > But after resizing it, the maximum resolution is 1600x1200. > > Also adding a new modeline does not help as it is accepted for the first > time but not being displayed nor possible to select it. > > Any suggestions would be nice. Well, maybe you will have to get 3rd display? I am in a similar problematic and this looks like best thing to do... Additionally, you won't have to do all the movement each time your girlfriend needs a PC. Just an extra screen, which will mostly be unused. Choice is yours. You can* also start that Xephyr maximised on second screen - Xinerama supports it! Should work fine, if your girlfried makes no security threat to you :) (in a case when you have to leave your session open) * is an indirect conclusion, which has some assumptions I am currently slowly testing those things, so not many questions I can answer, just some ideas. Regards > > -- > xrandr-1.2.3 > xorg-server-1.5.2 > > Portage 2.2_rc15 (default/linux/amd64/2008.0, gcc-4.3.2, > glibc-2.8_p20080602- r0, 2.6.27.6 x86_64) > System uname: > Linux-2.6.27.6-x86_64-AMD_Phenom-tm-_9850_Quad-Core_Processor- > with-glibc2.2.5 > -- > > Thanks > Tobi > ___ > 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: dvorak works fine, but ctrl+ is wrong (not even qwerty)
On Thu, Nov 20, 2008 at 09:24:56AM +0100, Dieter Plaetinck wrote: > I'm using a regular ps/2 azerty keyboard but with dvorak layout. The > problem is the dvorak layout by itself works fine, but when I press (and > hold) ctrl the other buttons behave totally differently, some seem to be > qwerty again but sometimes it's even different. > I test this in urxvt and xterm, so no gtk or gnome is involved (not that > I know) > Examples: (xev output follows later) > * ctrl+c becomes ctrl+i (dvorak c is on qwerty i) > * ctrl+j on dvorak does not become ctrl+c (what it would be in qwerty). > * ctrl+a only produces a ctrl character. I tried reproducing your problem a few days ago but failed. Please open a bugreport and attach the output of xkbcomp -xkb :0 -. Don't think there'll be anything interesting, but it might be a start. > * xev ctrl+j > > KeyPress event, serial 29, synthetic NO, window 0x1c1, > root 0x188, subw 0x0, time 1240357, (171,-26), root:(197,69), > state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyPress event, serial 32, synthetic NO, window 0x1c1, > root 0x188, subw 0x0, time 1241550, (171,-26), root:(197,69), > state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, > XLookupString gives 1 bytes: (0a) " > " > XmbLookupString gives 1 bytes: (0a) " > " > XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x1c1, > root 0x188, subw 0x0, time 1241644, (171,-26), root:(197,69), > state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, > XLookupString gives 1 bytes: (0a) " > " > XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x1c1, > root 0x188, subw 0x0, time 1242297, (171,-26), root:(197,69), > state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, > XLookupString gives 0 bytes: > XFilterEvent returns: False at least this one doesn't look weird, the other two are different. Have you tried starting a plain X server with nothing but xterm? Does this reproduce the issue? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Simulating a lower resolution on the OLPC XO Laptop
Hi, I have a XO Laptop which is a nice machine machine with a high res display of 1200x900 pixels. The problem with this is that the laptop isn't powerful enugh to handle fullscreen applications at this resolution. If only the display could switch to a lower resolution things would be much better but it seems that this laptop only supports a single resolution. So I was wondering if it would be possible of simulating lower res at a low level, that is the xf86-video-geode driver. I'm not an expert in video drivers but i imagine that there are functions to request a pixel to be drawn on screen based on what's in the video ram. Now let's say that it's not one pixel but two that we put on screen, and that we draw each lines two times. That would result in a 600x450 resolution. If we do the same thing but repating the operations three times , we would have a 400x300 resolution. Some emulators have a scale option to do such a thing and manage it quite well, but if we had such an option in the video driver, the result would be even faster ! So what do you think about this? Is it possible ? Regards, Mathieu ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is Xephyr going to support GLX in a near future?
Kārlis Repsons wrote: > One more sad thing: Xephyr doesn't support GLX, which means, most likely no > 3D > for it's users... I would like to ask someone better informed here, if that > is going to be addressed in near future? From an earlier post by ajax: "Xephyr supports GLX. It's even accelerated in 1.5. I think the acceleration support requires the use of a DRI driver under the skin (ie, not nVidia's driver), but I could be wrong." ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is Xephyr going to support GLX in a near future?
On Tuesday 25 November 2008 13:11:24 you wrote: > Kārlis Repsons wrote: > > One more sad thing: Xephyr doesn't support GLX, which means, most likely > > no 3D for it's users... I would like to ask someone better informed here, > > if that is going to be addressed in near future? > > From an earlier post by ajax: > > "Xephyr supports GLX. It's even accelerated in 1.5. I think the > acceleration support requires the use of a DRI driver under the skin > (ie, not nVidia's driver), but I could be wrong." Oh, glad to see, I am wrong about that, but still: the quote above makes me ask, if its possible to use nvidia cards with Xephyr properly (that is, use their capabilities, not make CPU work more)? Anyone here knows that? Well, anyway, later I will try with glxgears. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ctrl+ incorrect/missing keycodes with dvorak layout
Hi again list, I still haven't managed to figure this one out. the resulting keycodes when holding control are 'weird', to say at least. Any help is appreciated. Dieter Plaetinck wrote: > Hi list, > I'm using: > xorg 7.4 > xorg-server 1.5.3 > xkeyboard-config 1.4 > > I'm using a regular ps/2 azerty keyboard but with dvorak layout. The > problem is the dvorak layout by itself works fine, but when I press (and > hold) ctrl the other buttons behave totally differently, some seem to be > qwerty again but sometimes it's even different. > I test this in urxvt and xterm, so no gtk or gnome is involved (not that > I know) > Examples: (xev output follows later) > * ctrl+c becomes ctrl+i (dvorak c is on qwerty i) > * ctrl+j on dvorak does not become ctrl+c (what it would be in qwerty). > * ctrl+a only produces thew ctrl character. > > I have this problem both with hal hotplugging and with the classic > method (autoadddevices false). > I have this with both layout dvorak and dvorak-intl. > setxkbmap -layout dvorak[-intl] doesn't change anything > > [EMAIL PROTECTED] ~ $ setxkbmap -v > Trying to build keymap using the following components: > keycodes: xfree86+aliases(qwerty) > types: complete > compat: complete > symbols:pc+us(dvorak-intl) > geometry: pc(pc104) > > ( I posted my xorg.conf and fdi file here: > http://bbs.archlinux.org/viewtopic.php?pid=451182#p451182 ) > > [EMAIL PROTECTED] ~ $xmodmap -pke # some relevant keys > keycode 31 = c C c C ccedilla dead_abovedot > keycode 38 = a A a A agrave > keycode 39 = o O o O ocircumflex > keycode 40 = e E e E eacute > keycode 41 = u U u U ucircumflex > keycode 42 = i I i I icircumflex > > > And now, the xev's: > > * xev ctrl+c (press+hold ctrl, press c, release c, release ctrl !) > KeyPress event, serial 32, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1817959, (170,-29), root:(196,66), >state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLookupString gives 0 bytes: >XmbLookupString gives 0 bytes: >XFilterEvent returns: False > > FocusOut event, serial 32, synthetic NO, window 0x1c1, >mode NotifyGrab, detail NotifyAncestor > > FocusIn event, serial 32, synthetic NO, window 0x1c1, >mode NotifyUngrab, detail NotifyAncestor > > KeymapNotify event, serial 32, synthetic NO, window 0x0, >keys: 4294967176 0 0 0 32 0 0 0 0 0 0 0 0 > 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > KeyRelease event, serial 32, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1820112, (170,-29), root:(196,66), >state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLookupString gives 0 bytes: >XFilterEvent returns: False > > > > * xev ctrl+j > > KeyPress event, serial 29, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1240357, (171,-26), root:(197,69), >state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLookupString gives 0 bytes: >XmbLookupString gives 0 bytes: >XFilterEvent returns: False > > KeyPress event, serial 32, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1241550, (171,-26), root:(197,69), >state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, >XLookupString gives 1 bytes: (0a) " > " >XmbLookupString gives 1 bytes: (0a) " > " >XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1241644, (171,-26), root:(197,69), >state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, >XLookupString gives 1 bytes: (0a) " > " >XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x1c1, >root 0x188, subw 0x0, time 1242297, (171,-26), root:(197,69), >state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLookupString gives 0 bytes: >XFilterEvent returns: False > > > * xev ctrl+a (press+hold ctrl, press a, release a, release ctrl !) > > KeyPress event, serial 29, synthetic NO, window 0x181, >root 0x188, subw 0x0, time 16768525, (171,-26), root:(185,38), >state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLookupString gives 0 bytes: >XmbLookupString gives 0 bytes: >XFilterEvent returns: False > > FocusOut event, serial 32, synthetic NO, window 0x181, >mode NotifyGrab, detail NotifyAncestor > > FocusIn event, serial 32, synthetic NO, window 0x181, >mode NotifyUngrab, detail NotifyAncestor > > KeymapNotify event, serial 32, synthetic NO, window 0x0, >keys: 4294967290 0 0 0 32 0 0 0 0 0 0 0 0 0 > 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > KeyRelease event, serial 32, synthetic NO, window 0x181, >root 0x188, subw 0x0, time 16770786, (171,-26), root:(185,38), >state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >XLo
Re: DeliverPropertyEvent() accessing unallocated memory
Adam Jackson wrote:
> On Sat, 2008-11-22 at 13:07 +0100, Matthieu Herrb wrote:
>> Matthieu Herrb wrote:
>>> Hi,
>>>
>>> using OpenBSD's memory allocator (which has an option to fill free()'d
>>> memory with a specific pattern) I found out that xserver 1.5.3 is
>>> dumping core on exit.
>> Same problem on git's master.
>>
>>> This is caused by a bad pointer caused by accessing free'd memory in
>>> DeliverPropertyEvent, because when the RRProperties are destroyed, the
>>> associated windows have been free'd already.
>>>
>> So, no help on how to fix that? Should we just remove
>> RRDeleteAllOutputProperties() since it can't work?
>
> It does work, when outputs are deleted at runtime. It just can't work
> during server shutdown since windows are already gone, so there's
> nothing to deliver events to.
>
> Something like this maybe:
>
> --- a/randr/rrproperty.c
> +++ b/randr/rrproperty.c
> @@ -59,7 +59,8 @@ DeliverPropertyEvent(WindowPtr pWin, void *value)
>
> static void RRDeliverPropertyEvent(ScreenPtr pScreen, xEvent *event)
> {
> -WalkTree(pScreen, DeliverPropertyEvent, event);
> +if (!(dispatchException & (DE_RESET | DE_TERMINATE)))
> + WalkTree(pScreen, DeliverPropertyEvent, event);
> }
>
> void
>
> ---
Thanks for the answer. That seems to work indeed.
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Simulating a lower resolution on the OLPC XO Laptop
On Tue, Nov 25, 2008 at 12:52 PM, <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 11:57:17AM +0100, Strider wrote: > > The problem with this is that the laptop isn't powerful enugh > > to handle fullscreen applications at this resolution. > > All those I have tried have worked fine at this resolution. Which > particular applications are you referring to? > > I've tried; konqueror, galeon, gpredict, xclock, firefox, emacs, xterm, > inkscape, gimp, abiword, openoffice, wesnoth, and xastir. I'm probably > not using an application you're using. Which is it? Perhaps there is a > design problem in the application. Perhaps the application requires a > display bandwidth that exceeds what is available. > > -- > James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ It is indeed the applications that are in cause. I tried zsnes which is not usable in other resolution than the original 256x224, I also ran the amiga emulator e-uae which does not support upscaling but only resolution changes. Other emulators such as dgen for the Sega Genesis or gnuboy for the game boy have a software scaling option working really well. One solution would be to patch each problematic application to support 1200x900 but it's will not be possible with closed source software. I'd also like to try to run games that ran on 1999's PCs such as Quake 3 and Unreal Tournament, I think the laptop is powerful enough to run these games at a 400x300 resolution but i doubt it will be smooth at 1200x900. I have found this message : http://lists.x.org/archives/xorg-driver-geode/2008-August/000353.html on the x.org mailing list and it might be what i'm talking about, I have to give it a try. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Additional NULL (??) layout group with evdev+hal
Hi Peter,
I`m just new to all this, but here is something odd:
...
key {
type[group1]= "FOUR_LEVEL",
symbols[Group1]= [less, greater, bar,
brokenbar ],
symbols[Group2]= [less, greater ],
symbols[Group3]= [ bar ]
};
...
group1: German keyboard
group2: Japanese
This seems refer a key ONLY available in German Keyboard layout (it
doesn`t exist on Japanese keyboard).
I can understand this is here and group1 one get's type `FOUR_LEVEL"
as I have 3rd level indicator active (e.g. for € or @ in German
keyboard).
What I don`t understand is group2... simply there is not such a key on
a Japanese keyboards (but separate key with comma/less and
period/greater).
Here what I think:
1) Where are these symbols come from? --> It looks like a copy of
German keyboard layout
2) There is no special type assigned to group2 --> I just had a few
minutes to read in the xkb specs (e.g. chapter 12.2.2 Assigning
Symbols To Groups),,, I'm maybe not correct but 2 shift levels are
maybe the standard if no keytype is indicating somethings else
As a result the system "implicitly" seems to assume a 3rd group (as
this would the the standard distribution of the symbols. So the copied
(??) "bar" might be in this 3rd group.
The source is a little bit complex for a keyboard novice, but this
comment you made
here:
/* See XKB Protocol Sec, Section 12.4.
A 1-group key with ABCDE on a 2 group keyboard must be
duplicated across all groups as ABABCDECDE.
*/
This seems to somehow indicate a little you are duplicating here entries.
Just a speculation: This might be in general OK, but I wonder such
special keys (e.g. just existing in German OR Japanese but not in
both). Does this still work correctly?
(especially having (maybe) not the key type ("FOUR_LEVEL") copied too?
Sorry for bothering you so much about this and thanks so much for your help.
Cheers,
Thomas
On Tue, Nov 25, 2008 at 8:44 PM, Thomas Fritzsche <[EMAIL PROTECTED]> wrote:
> Hello Peter,
>
> output of "X -version":
> ..
> X.Org X Server 1.5.2
> Release Date: 10 October 2008
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 2.6.24-19-server i686 Ubuntu
> Current Operating System: Linux sakura 2.6.27-7-generic #1 SMP Tue Nov
> 4 19:33:20 UTC 2008 i686
> Build Date: 24 October 2008 08:00:16AM
> .
>
> I double checked the source package contains the patches (as expected).
> There are some other patches applied by Ubuntu, relevant for keyboard
> seems to be only this one:
> ...
> From 638cab7e1dc3711f7fb04155bcdabf4b8895cc5e Mon Sep 17 00:00:00 2001
> From: Peter Hutterer <[EMAIL PROTECTED]>
> Date: Mon, 4 Aug 2008 17:08:36 +0930
> Subject: [PATCH] xfree86: force SwitchCoreKeyboard for evdev devices
> (updated).
>
> If an evdev keyboard device is added through the HAL mechanism, force a
> SwitchCoreKeyboard to load the evdev map into the VCK. This way, by the time a
> client starts the evdev keymap is already there, leading to less pain lateron.
> ...
>
> I attached another "xkbcomp -xkb :0 -" output. This run is just a pure
> X session with xterm but nothing else.
>
> There is one warning that comes up when executing "xkbcomp -xkb :0 -":
> ...
> Warning: Could not load keyboard geometry for :0
> BadAlloc (insufficient resources for operation)
> Resulting keymap file will not describe geometry
> ...
> (as it's on stderr it didn't show in the files attached before)
> This warning comes ONLY when I have this strange 3rd layout group.
> After calling manually setxkbmap it doesn't show this warning any more.
>
> Thanks for your help!
> Cheers,
> Thomas
>
> On Tue, Nov 25, 2008 at 1:35 PM, Peter Hutterer
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Nov 25, 2008 at 11:11:29AM +0900, Thomas Fritzsche wrote:
>>> Hello Peter,
>>> That's oddI have installed latest Ubuntu package for xorg-server
>>> and this is 1.5.2.
>>> http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg-server/xorg-server_1.5.2-2ubuntu3/changelog
>>
>> 2:1.5.1-1ubuntu3 should have the patch and unless it disappeared since, it
>> should still be in there.
>>
>>> Is there any more information I can provide you except of the earlier
>>> attached output from "xkbcomp -xkb :0 -" ?
>>
>> Please try to find the simplest reproduceable test-case. Ideally, this would
>> be a plain X server with nothing but xterm (or even just the X server
>> itself).
>>
>> Other than that, it's pretty much down to looking at the code.
>>
>> Cheers,
>> Peter
>>
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Siliconmotion driver update for XFree 4.3?
Dear list, in the past, our company got a siliconmotion driver update to release 1.4.9 of the siliconmotion driver. But it seems that the features of the 1.4.9 release have not been given back to the xorg developer community. I have the source code for this release, and it can be compiled against XFree 4.3. Now as we want to change to newer Linux distributions, also the Xorg version increases to Xorg 7.1 or newer. But: On the one hand the siliconmotion driver part of Xorg 7.1 does not have the features we had in release 1.4.9. On the other hand I can not simply recompile the 1.4.9 sources against Xorg 7.1. Does it make sense when I create a diff between my siliconmotion 1.4.9 source code and the original siliconmotion source code part of XFree 4.3? Maybe with such a patch, there would be a simple way to port the new siliconmotion driver release to the current Xorg version? btw: sorry for the long signature at the bottom, it's automatically added :-( Best Regards Björn -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Siliconmotion driver update for XFree 4.3?
Gerhart, Bjoern wrote: > Dear list, Hi, > in the past, our company got a siliconmotion driver update to release > 1.4.9 of the siliconmotion driver. But it seems that the features of > the 1.4.9 release have not been given back to the xorg developer > community. I have the source code for this release, and it can be > compiled against XFree 4.3. It is not that it has not been given back, in most cases, it is just that they lost contacts with opensource developers, or there wasn't any developer working on integrating their patches. I have the latest sources from siliconmotion, and I have been on contact with them for some time now. If you are using XFree86, probably you will want to use that version, that you can also get from http://www.loongson.cn/support/cgi-bin/gitweb/gitweb.cgi?p=siliconmotion/xorg;a=summary You may also want to check the latest freedesktop git, just run: git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-siliconmotion There isn't yet an official version, so you need a snapshot. But some of the features in that driver include randr 1.2 (with multihead), exa, basic composite accel, compatible with xorg latest xorg xserver, etc. > Now as we want to change to newer Linux distributions, also the Xorg > version increases to Xorg 7.1 or newer. But: On the one hand the > siliconmotion driver part of Xorg 7.1 does not have the features we > had in release 1.4.9. On the other hand I can not simply recompile > the 1.4.9 sources against Xorg 7.1. What features you had? Anyway, note that I am working mainly on the smi 501/502 support, but Francisco Jerez did a lot of work for the Lynx3D chipsets, and is the main author of several new features like the randr 1.2 (I only adapted that code to smi 501). I have been working on an some experiments with a drm module for the smi 501, the hardware doesn't have 3d support, but it has a "batch buffer" and dma transfers from/to system/video memory, and Francisco also did some work on implementing composite on top of Lynx3D hardware. Hopefully that can also be integrated soon. > Does it make sense when I create a diff between my siliconmotion > 1.4.9 source code and the original siliconmotion source code part of > XFree 4.3? Maybe with such a patch, there would be a simple way to > port the new siliconmotion driver release to the current Xorg > version? They are already in version 2.2.8, while we are on version 1.6.1 :-) If you can send me the tarball it should be easier to handle, then real diffs. As there may exist useful features that were removed... > btw: sorry for the long signature at the bottom, it's automatically > added :-( > > Best Regards Björn Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6_beta1 pending pixman
Keith Packard <[EMAIL PROTECTED]> writes: > So, we'll see if we can't get a bit of pixman review and perhaps a > pixman release done tomorrow so that the X server beta can head out. Here are some comments on the matrix code. I didn't review all the numericals, but nothing jumped out at me either. - I'd like to have the interface const correct, for example in pixman_transform_multily (struct pixman_transform_t *dst, struct pixman_transform_t *l, struct pixman_transform_t *r); l and r could be const - For the rotation interfaces, maybe expand the names s and c to sin and cos? I first thought c meant center and was then mystified what s could mean. - The interfaces that take forward/reverse matrices should probably accept NULL's. - Pixman's version numbering scheme is similar to cairo's: The git master version has an odd micro number, released versions have even micro numbers. - The name pixman_f_transform bothers me, but I don't have a better suggestion since pixman_transformf would be worse. - Is there any particular reason for the fixed point epsilon of 2 (as opposed to 1)? - There is a comment about floating point interfaces, but the file contains both fixed and floating point interfaces. Thanks, Soren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dvorak works fine, but ctrl+ is wrong (not even qwerty)
Peter Hutterer wrote: On Thu, Nov 20, 2008 at 09:24:56AM +0100, Dieter Plaetinck wrote: I'm using a regular ps/2 azerty keyboard but with dvorak layout. The problem is the dvorak layout by itself works fine, but when I press (and hold) ctrl the other buttons behave totally differently, some seem to be qwerty again but sometimes it's even different. I test this in urxvt and xterm, so no gtk or gnome is involved (not that I know) Examples: (xev output follows later) * ctrl+c becomes ctrl+i (dvorak c is on qwerty i) * ctrl+j on dvorak does not become ctrl+c (what it would be in qwerty). * ctrl+a only produces a ctrl character. I tried reproducing your problem a few days ago but failed. Please open a bugreport and attach the output of xkbcomp -xkb :0 -. Don't think there'll be anything interesting, but it might be a start. * xev ctrl+j KeyPress event, serial 29, synthetic NO, window 0x1c1, root 0x188, subw 0x0, time 1240357, (171,-26), root:(197,69), state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 32, synthetic NO, window 0x1c1, root 0x188, subw 0x0, time 1241550, (171,-26), root:(197,69), state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, XLookupString gives 1 bytes: (0a) " " XmbLookupString gives 1 bytes: (0a) " " XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1c1, root 0x188, subw 0x0, time 1241644, (171,-26), root:(197,69), state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, XLookupString gives 1 bytes: (0a) " " XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1c1, root 0x188, subw 0x0, time 1242297, (171,-26), root:(197,69), state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False at least this one doesn't look weird, the other two are different. Have you tried starting a plain X server with nothing but xterm? Does this reproduce the issue? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Peter, thank you so much. I've spent way too much time searching in the wrong direction. When starting x with plain xterm/urxvt all was fine, so gradually I could build up my environment and check where it went wrong. As it turned out the culprit is compiz: compiz --replace --sm-disable --ignore-desktop-hints ccp <-breaks keys compiz --replace --sm-disable --ignore-desktop-hints <- doesn't break keys I'll now try to figure out why the 'core plugin' changes my keys (maybe it's me who configured something incorrectly) Thanks, Dieter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6_beta1 pending pixman
On Tue, 2008-11-25 at 17:58 +0100, Soeren Sandmann wrote: > Keith Packard <[EMAIL PROTECTED]> writes: > > > So, we'll see if we can't get a bit of pixman review and perhaps a > > pixman release done tomorrow so that the X server beta can head out. > > Here are some comments on the matrix code. I didn't review all the > numericals, but nothing jumped out at me either. I just copied the code from the X server where it hasn't demonstrated any problems. I think most of the paths are actually tested in the projective transform RandR work too. > - I'd like to have the interface const correct, for example in > > pixman_transform_multily (struct pixman_transform_t *dst, > struct pixman_transform_t *l, > struct pixman_transform_t *r); Yeah, I briefly considered doing that; I'll go fix it. > - For the rotation interfaces, maybe expand the names s and c to sin > and cos? I first thought c meant center and was then mystified what > s could mean. Ok. > - The interfaces that take forward/reverse matrices should probably > accept NULL's. Ok. > - Pixman's version numbering scheme is similar to cairo's: The git > master version has an odd micro number, released versions have even > micro numbers. What version would you like? > - The name pixman_f_transform bothers me, but I don't have a better > suggestion since pixman_transformf would be worse. I'll leave this alone then. > - Is there any particular reason for the fixed point epsilon of 2 (as > opposed to 1)? Just giving more space to allow for rounding errors. > - There is a comment about floating point interfaces, but the file > contains both fixed and floating point interfaces. I'll fix the comment. Thanks for the review! -- [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: X server 1.6_beta1 pending pixman
Keith Packard <[EMAIL PROTECTED]> writes: > > - Pixman's version numbering scheme is similar to cairo's: The git > > master version has an odd micro number, released versions have even > > micro numbers. > > What version would you like? Before releasing, bump to 0.13.2, after releasing, bump to 0.13.3. Or if you don't want to release, but still want a number to depend on, just bump to 0.13.3. Soren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [synaptics] [patch] touchpad output noise that confuse driver
On Tue, Nov 25, 2008 at 09:46:38AM +1000, Peter Hutterer wrote: > On Sun, Nov 23, 2008 at 08:46:14PM +0100, Batchty wrote: > > Hello, I have a Dell Inspiron 1520 with a Synaptics touchpad. This touchpad > > for > > a unknown reason loves to send event like these after every finger release > > : > > > > time xy z f w l r u d m multi gl gm gr gdx gdy > >1.563 3224 1625 57 1 5 0 0 0 0 0 0 0 0 0 0 > >1.574 3251 1632 30 1 5 0 0 0 0 0 0 0 0 0 0 > >1.584 3292 1673 10 1 5 0 0 0 0 0 0 0 0 0 0 > >1.594 1 5855 3 2 5 0 0 0 0 0 0 0 0 0 0 > >1.634 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > >1.746 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 > >1.897 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > > > > Most of the time these events are ignored by the driver. but sometimes > > it confuse two-finger scrolling and tap detection. ... > > Oh, and thanks for maintaining this driver. :) i tried to contact previous > > upstream but they didn't answer. > > Pushed, thanks a lot! Looks like this was http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437254 and https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/133060 but I can't find the issue in the freedesktop bugzilla (was it never forwarded upstream)? It's great to have it fixed. Marius Gedminas -- This loads a GDT entry into the "Task Register": that entry points to a structure called the Task State Segment. Some comments scattered though the kernel code indicate that this used for task switching in ages past, along with blood sacrifice and astrology. -- lguest source code signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6_beta1 pending pixman
On Tue, 2008-11-25 at 19:17 +0100, Soeren Sandmann wrote:
> Keith Packard <[EMAIL PROTECTED]> writes:
>
> > > - Pixman's version numbering scheme is similar to cairo's: The git
> > > master version has an odd micro number, released versions have even
> > > micro numbers.
> >
> > What version would you like?
>
> Before releasing, bump to 0.13.2, after releasing, bump to 0.13.3. Or
> if you don't want to release, but still want a number to depend on,
> just bump to 0.13.3.
Ok, so I've set it to 0.13.2 in this patch:
From ba65df0b2ac45582eba952acad31ce6a8c61c2f2 Mon Sep 17 00:00:00 2001
From: Keith Packard <[EMAIL PROTECTED]>
Date: Mon, 24 Nov 2008 11:49:32 -0800
Subject: [PATCH] Move matrix operations from X server to pixman
Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
---
configure.ac |2 +-
pixman/Makefile.am |3 +-
pixman/pixman-matrix.c | 598
pixman/pixman-utils.c | 32 ---
pixman/pixman.h| 150 -
5 files changed, 748 insertions(+), 37 deletions(-)
create mode 100644 pixman/pixman-matrix.c
diff --git a/configure.ac b/configure.ac
index 7937f95..063f6eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,7 +54,7 @@ AC_PREREQ([2.57])
m4_define([pixman_major], 0)
m4_define([pixman_minor], 13)
-m4_define([pixman_micro], 1)
+m4_define([pixman_micro], 2)
m4_define([pixman_version],[pixman_major.pixman_minor.pixman_micro])
diff --git a/pixman/Makefile.am b/pixman/Makefile.am
index 6d5a643..c4612ea 100644
--- a/pixman/Makefile.am
+++ b/pixman/Makefile.am
@@ -26,7 +26,8 @@ libpixman_1_la_SOURCES = \
pixman-edge-imp.h \
pixman-trap.c \
pixman-compute-region.c \
- pixman-timer.c
+ pixman-timer.c \
+ pixman-matrix.c
libpixmanincludedir = $(includedir)/pixman-1/
libpixmaninclude_HEADERS = pixman.h pixman-version.h
diff --git a/pixman/pixman-matrix.c b/pixman/pixman-matrix.c
new file mode 100644
index 000..28124bd
--- /dev/null
+++ b/pixman/pixman-matrix.c
@@ -0,0 +1,598 @@
+/*
+ * Copyright © 2008 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/*
+ * Floating point matrix interfaces
+ */
+
+#include "config.h"
+#include
+#include
+#include "pixman-private.h"
+
+#define F(x) pixman_int_to_fixed(x)
+
+PIXMAN_EXPORT void
+pixman_transform_init_identity(struct pixman_transform *matrix)
+{
+ int i;
+
+ memset(matrix, '\0', sizeof (struct pixman_transform));
+ for (i = 0; i < 3; i++)
+ matrix->matrix[i][i] = F(1);
+}
+
+typedef pixman_fixed_32_32_t pixman_fixed_34_30_t;
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point_3d(const struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ struct pixman_vector result;
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_48_16_t v;
+ int i, j;
+
+ for (j = 0; j < 3; j++)
+ {
+ v = 0;
+ for (i = 0; i < 3; i++)
+ {
+ partial = ((pixman_fixed_48_16_t)
transform->matrix[j][i] *
+ (pixman_fixed_48_16_t) vector->vector[i]);
+ v += partial >> 16;
+ }
+ if (v > pixman_max_fixed_48_16 || v < pixman_min_fixed_48_16)
+ return FALSE;
+ result.vector[j] = (pixman_fixed_t) v;
+ }
+ *vector = result;
+ if (!result.vector[2])
+ return FALSE;
+ return TRUE;
+}
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point(const struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_34_30_t v[3];
+ pixman_fixed_48_1
Re: Possible bitrot detected while compiling full xorg tree
Alex Villacís Lasso wrote: > - driver/xf86-video-via generates an error about "expected > specifier-qualifier-list before 'uint32_t'" when including drm.h. I > skipped this one since my chipset is a radeon. That's rotted alright - I've pushed a build.sh change to stop building it. (The replacement, xf86-video-openchrome, doesn't live in X.Org's git repos, so needs to be grabbed & built on it's own.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
EXA and migration [was: shrink xrender featureset]
> Sorry just to clarify - can't Xorg draw a gradient directly to the pixmap > over PCI, rather than migrating the pixmap out of the video card? We've been flaming on this subject on this list before. Apparently, the current incarnation of EXA is built on the assumption that everything should be accelerated, and that when it isn't, it's a bug. Hence, it pays no attention whatsoever to the performance of software rendering. (Strong vocabulary chosen deliberately, to get some EXA expert to react.) Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Well if you let me decide between software rendering on client or > software rendering on server, I would prefer the latter. It's not that clear cut. At least some of the motivation behind Render is about moving time-consuming operations into the client, notably font rasterisation. There are two reasons why you may want to move stuff into the client. One is flexibility: for most users, it's easier to install a new version of a library, than a new version of the X server. This was the principal reason why Render moves font rasterisation into the client. The other point is that having time-consuming operations in the server increases client latency. Before Render, all font rasterisation happened in the server, and this would cause noticeable pauses (with the whole server frozen, not just a single client). While it is possible to implement background processing in the server, using ``Block Handlers'' (that's how I implemented the now-deceased XFree86 DPS extension), it's difficult, error-prone, and there are just three people in the universe who know how it's done. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA and migration [was: shrink xrender featureset]
On Tue, 2008-11-25 at 19:54 +0100, Juliusz Chroboczek wrote: > > Sorry just to clarify - can't Xorg draw a gradient directly to the pixmap > > over PCI, rather than migrating the pixmap out of the video card? > > We've been flaming on this subject on this list before. > > Apparently, the current incarnation of EXA is built on the assumption that > everything should be accelerated, and that when it isn't, it's a bug. Hence, > it pays no attention whatsoever to the performance of software rendering. > > (Strong vocabulary chosen deliberately, to get some EXA expert to react.) That's not 'strong vocabulary' but simply baseless flamebait. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA and migration [was: shrink xrender featureset]
> That's not 'strong vocabulary' but simply baseless flamebait. Would it make sence to implement some fallback-optimizations like: - Copy pictures without drawables (gradients) to a temporary surface, if the driver supports composition? - Support solid write-only operations (X11 core drawing) for which EXA does not provide hooks (e.g. diagonal lines) through a temporal mask, if the driver supports composition? For both cases I saw ping-pong migration killing performance, and I had to implement work-arrounds in my application myself which are built on assumptions about the accaleration architecture's behaviour and sometimes cause degraded performance. By the way thanks a lot for the EXA improvements in 1.5/1.6 :) - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> The other point is that having time-consuming operations in the server > increases client latency. Before Render, all font rasterisation happened > in the server, and this would cause noticeable pauses (with the whole > server frozen, not just a single client). Wasn't the reason to do font rasterization primiary to give applications more control over font rendering? After all isn't that just an implementation problem of the xserver? When doing e.g. gradients client-side, all hope for hw accaleration is lost, furthermore it would mean transferring a _lot_ of data between the client and the server which would pretty much kill network performance. Furthermore it would lead to more frequent syncs (when shm is used) or increased copy-overhead (when going through protocol). - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA and migration [was: shrink xrender featureset]
On Wed, Nov 26, 2008 at 5:38 AM, Clemens Eisserer <[EMAIL PROTECTED]> wrote: >> That's not 'strong vocabulary' but simply baseless flamebait. > > Would it make sence to implement some fallback-optimizations like: > - Copy pictures without drawables (gradients) to a temporary surface, > if the driver supports composition? > - Support solid write-only operations (X11 core drawing) for which EXA > does not provide hooks (e.g. diagonal lines) through a temporal mask, > if the driver supports composition? > > For both cases I saw ping-pong migration killing performance, and I > had to implement work-arrounds in my application myself which are > built on assumptions about the accaleration architecture's behaviour > and sometimes cause degraded performance. > > By the way thanks a lot for the EXA improvements in 1.5/1.6 :) Yeah I'm with this, EXA really needs optimisations that know you have composite, and just to render the stuff with the CPU and composite it on. Generally it does stupid things like fill on the GPU, then render with CPU then composite. When you have kernel managed pixmaps and they are uncached CPU side for the GPU to use them EXA isn't currently the acceleration architecture you are looking for. I'm starting to think a bit more about the requirements on the XA for sw fallbacks in this case. another things that would be nice, would be instead of the current prepare/op/op/op/done, we could possibly tell prepare how many ops are coming so it can more efficiently batch things. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [synaptics] [patch] touchpad output noise that confuse driver
Marius Gedminas wrote : > but I can't find the issue in the freedesktop bugzilla (was it never > forwarded upstream)? It was forwarded to the old upstream (http://web.telia.com/~u89404340/touchpad/) which was half-dead back then. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA and migration
>> Apparently, the current incarnation of EXA is built on the assumption that >> everything should be accelerated, and that when it isn't, it's a bug. Hence, >> it pays no attention whatsoever to the performance of software rendering. > That's not 'strong vocabulary' but simply baseless flamebait. Sorry if you took it that way. I think you'll agree that current incarnations of EXA do some rather silly things when some, but not all operations in a sequence can be accelerated. Since some rather smart people are working on EXA, I have trouble understanding why this rather obvious shortcoming. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Blend modes take 3
"Benjamin Otte" <[EMAIL PROTECTED]> writes:
> On Wed, Nov 19, 2008 at 7:00 PM, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
> > Hi Benjamin,
> >
> > Overall, the separable blend mode stuff looks good, except for the
> > component alpha versions.
> >
> New update pushed to my git branches of pixman/cairo.
Comments on separable blend modes:
- In both fbCombineMultiplyC and fbCombine ## name ## C,
- When mask is 0, there is no reason to read the source.
- The continue is incorrect; it needs to write out 0 in that case,
since the intermediate buffer is not zero-filled.
- In fbCombineMultiplyC,
- There is no reason to read the destination if the inverse
combined src/mask is 0
- In FlashSubtractC, the m = ~m is not used. And fbCombineMaskC()
seems like it could just be fbCombineMaskValueC.
I still don't completely understand the non-separable blend modes, and
how they interact with premultiplied alpha and with component
alpha. But here are some questions about the code:
- In SetLum and SetSat you have, respectively:
> if (Max (tmp) > sa) while (1);
> if (Max (dest) > 255 * 255) while (1);
Are these supposed to never happen?
- In SetLum:
> if (min < 0) {
>tmp[0] = l + (tmp[0] - l) / 4 * l / (l - min) * 4;
>tmp[1] = l + (tmp[1] - l) / 4 * l / (l - min) * 4;
>tmp[2] = l + (tmp[2] - l) / 4 * l / (l - min) * 4;
> }
> if (max > a) {
>tmp[0] = l + (tmp[0] - l) / 4 * (a - l) / (max - l) * 4;
>tmp[1] = l + (tmp[1] - l) / 4 * (a - l) / (max - l) * 4;
>tmp[2] = l + (tmp[2] - l) / 4 * (a - l) / (max - l) * 4;
> }
Where do those 4s come from?
Soren
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Wasn't the reason to do font rasterization primiary to give applications > more control over font rendering? If memory serves, Keith was trying to find a design to solve both issues with core fonts -- lack of flexibility and latency. There was an extended brain-storming session on the old XFree86 list (Keith, Ralf, Rob Pike, myself, probably others I forget), and suddenly there was this collective insight -- client-side rasterisation solves both problems in an elegant way. > After all isn't that just an implementation problem of the xserver? The fact that other clients are locked out during font rasterisation is. However, it's tricky to fix -- it basically requires either threading the server, or converting your font rasteriser to continuation-passing style. The fact that fonts cannot be rasterised incrementally but must be fully rasterised at font open time, on the other hand, is a design flaw of the core fonts mechanism. (Due to the fact that the core protocol requires providing accurate ink metrics at font open time.) > When doing e.g. gradients client-side, all hope for hw accaleration is > lost, furthermore it would mean transferring a _lot_ of data between the > client and the server which would pretty much kill network performance. > Furthermore it would lead to more frequent syncs (when shm is used) or > increased copy-overhead (when going through protocol). In no way am I claiming that client-side gradients are the right solution. I'm simply saying that the client- vs. server-side debate is seldom as clear cut as a previous speaker made it, and that the pros and the cons need to be carefully weighted. My personal instincts tend to go towards client-side operations whenever possible -- every complex server-side operation I tend to see as a failure to design the right protocol-level abstractions. As far as network and SHM performance -- Keith convinced me at some point that we don't currently have a good pixmap transport extension. I'd like to see something that uses a windowed, non-blocking form of SHM when working locally, and some smart compression method when working remotely. (There's no reason why the compression mechanism shouldn't have an ad-hoc encoding for gradients, if gradients are found to be important.) Point taken about hw acceleration, although I happen to think (or hope) that hw acceleration of 2D graphics is going the way of the dodo. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
HOWTO for dual-head and ipnut device hotplugging
Hullo, you've probably seen me (ab)use this list (as well as the bugzilla and [EMAIL PROTECTED]) quite a bit in the past days. So, to make it up, I decided to write a HOWTO on what I learnt from all your help. I hope it's of any use to anyone: http://matija.suklje.name/?q=node/56 Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 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: Blend modes take 3
On Tue, Nov 25, 2008 at 10:10 PM, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
>- When mask is 0, there is no reason to read the source.
>
>- There is no reason to read the destination if the inverse
> combined src/mask is 0
>
Don't compilers take care of that?
The code looks better to me if the variable assignments all occur in one place.
>- The continue is incorrect; it needs to write out 0 in that case,
> since the intermediate buffer is not zero-filled.
>
Oh, the code is supposed to modify the _source_ parameter, too?
Someone really needs to document what component alpha does properly so
I really grok it.
Fixed.
> - In FlashSubtractC, the m = ~m is not used. And fbCombineMaskC()
> seems like it could just be fbCombineMaskValueC.
>
Fixed.
>> if (Max (tmp) > sa) while (1);
>> if (Max (dest) > 255 * 255) while (1);
>
> Are these supposed to never happen?
>
Yeah, It's my poor man's choice at an assertion statement while
debugging. Unfortunately I always forget removing them after I'm done
debugging.
Fixed.
>> if (min < 0) {
>>tmp[0] = l + (tmp[0] - l) / 4 * l / (l - min) * 4;
>>tmp[1] = l + (tmp[1] - l) / 4 * l / (l - min) * 4;
>>tmp[2] = l + (tmp[2] - l) / 4 * l / (l - min) * 4;
>> }
>> if (max > a) {
>>tmp[0] = l + (tmp[0] - l) / 4 * (a - l) / (max - l) * 4;
>>tmp[1] = l + (tmp[1] - l) / 4 * (a - l) / (max - l) * 4;
>>tmp[2] = l + (tmp[2] - l) / 4 * (a - l) / (max - l) * 4;
>> }
>
> Where do those 4s come from?
>
Overflow protection. The tmp value can range from -COMP2_T_MAX .. 2 *
COMP2_T_MAX (I think), so I took the shortcut to just divide by a high
enough number to avoid it. Also, this code will break on 64bit cases
as I'm using ints there for lack of a signed comp4_t type.
It's one of the cases I asked about previously on IRC I think as I was
unsure if this is a case for doubles or how it should best be handled.
Benjamin
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: HOWTO for dual-head and ipnut device hotplugging
On Tue, Nov 25, 2008 at 10:36:40PM +0100, Matija Šuklje wrote: > you've probably seen me (ab)use this list (as well as the bugzilla and > [EMAIL PROTECTED]) quite a bit in the past days. > > So, to make it up, I decided to write a HOWTO on what I learnt from all your > help. I hope it's of any use to anyone: > http://matija.suklje.name/?q=node/56 thanks for writing that up. Quick skim left me with two comments: synaptics fdi: don't specify the range unless you really need to. synaptics reads the range from the kernel and unless the hardware reports false ranges or you're not happy with the edges, don't specify them. "Now you can (and should) safely remove the mouse settings from the xorg.conf file:" that particular section wouldn't do anything even if you'd leave it in. It doesn't have a device option, so it's mute. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Simulating a lower resolution on the OLPC XO Laptop
Jordan Crouse a écrit : > Bert Freudenberg wrote: >> >> On 25.11.2008, at 17:37, Jordan Crouse wrote: >> >>> Bert Freudenberg wrote: On 25.11.2008, at 11:57, Strider wrote: > Hi, > I have a XO Laptop which is a nice machine machine with a high > res display of 1200x900 pixels. The problem with this is that the > laptop isn't powerful enugh to handle fullscreen applications at > this resolution. If only the display could switch to a lower > resolution things would be much better but it seems that this > laptop only supports a single resolution. > > So I was wondering if it would be possible of simulating lower > res at a low level, that is the xf86-video-geode driver. > I'm not an expert in video drivers but i imagine that there are > functions to request a pixel to be drawn on screen based on > what's in the video ram. > Now let's say that it's not one pixel but two that we put on > screen, and that we draw each lines two times. That would result > in a 600x450 resolution. > If we do the same thing but repating the operations three times , > we would have a 400x300 resolution. > Some emulators have a scale option to do such a thing and manage > it quite well, but if we had such an option in the video driver, > the result would be even faster ! > > So what do you think about this? Is it possible ? The Geode actually can do real upscaling (that is, scale multiple graphics resolutions to the panel resolution), it works fine on other machines and LCDs. But latest word is that this somehow interacts badly with our DCON, so no-one has gotten it to work correctly on the XO yet. >>> >>> Indeed. I think there is a DCON interaction happening, because the >>> mouse gets "corrupted" during upscaling as well - and that implies >>> that the issue is happening after the screen is constructed. The >>> upscaling works fine on a CRT and on a "standard" TFT panel, so that >>> is what leads me back to the DCON. Its also a long shot that the >>> 1200x900 resolution is confusing the scaler, but I doubt it since >>> the aspect ratio is still 4:3. I would love for other people to try >>> the driver (it is in the latest debxo, I think); perhaps you can see >>> the pattern that I can't. >>> There still may be hope, because the video upscaler can take RGB 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be upscaled on-the-fly (and the upscaler does 30 fps easily). But I guess getting this to work would require a very determined X hacker ... >>> >>> The RGB video overlay should just work (TM). So it would take less >>> of a determined X hacker, and more of a determined application >>> hacker to put all the pieces together. >> >> >> Well, I meant that this could be used to actually provide, say, an >> 800x600x16 mode in the driver, without having to hack applications. >> While adapting a single app may be comparatively easy, it's still a >> major hassle to patch each and every app. Having it in the driver >> would make things just work (TM). But that would be a major hack, >> don't you agree? > > So if I understand what you are getting at - you want to set up a > single overlay over the whole screen, and render everything on that? > Thats probably doable - you could set up a shadow framebuffer like we > do for rotation, and hook the damage code into the video overlay. It > might work out well, but it would preclude using the video overlay for > anything else (such as, video). It would probably also preclude > rotation - maybe not. > > But rather then invent fanciful ways to handle this, the efforts would > be better spent figuring out how to fix the current driver. Mitch > reports that the Windows driver works just fine, so clearly the bug is > on our side. > > We need developers to start understanding how the driver works. > Everybody with a professional interest in the X driver has moved on to > other pastures, and OLPC desperately needs community members to pick > up the slack. > > Jordan > Knowing that changing resolution on Windows XP sure brings hope to solve this problem :) I have installed the latest DebXO on a SD Card and xrandr shows several choices where Ubuntu and Fedora showed only the native 1200x900. I tried the other modes but they're all messed up. It's clearly a problem about timings. Here's a photo of what it looks like when I try run run Scummvm in fullscreen mode : http://img155.imageshack.us/img155/5589/img0700qg4.jpg I had a similar "out of sync" problem on my other laptop back when the radeon driver had problems on my display. Windows XP had no problems and I had a tool which allowed me to find the correct timing to add valid ModeLines to xorg.conf. Later versions of Ubuntu corrected this problem and I could switch resolutions without any problems. I hope the same t
Is it possible to use i810 driver in Xorg7.3 without agpgart kernel module
Hi All, Is it possible to use i810 driver in Xorg7.3 without agpgart kernel module ? I use kernel 2.4.31. And It's OK for XFree86 4.6. -- Regards, Paul Lin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Wed, Nov 19, 2008 at 10:07:59PM +, Magnus Kessler wrote:
> With the latest server and synaptics driver from git I can reliably crash
> the server by starting
>
> xinput test "SynPS2/2 Synaptics Touchpad"
>
> and then clicking the any of the physical buttons or tapping the pad to
> simulate a click.
How about this one?
>From 87f5aa009d65e44f516bfc0168249ea29433b2b4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Wed, 26 Nov 2008 12:20:00 +1000
Subject: [PATCH] xkb: don't attempt to filter events for devices without key
classes.
Reported by Magnus Kessler.
Signed-off-by: Peter Hutterer <[EMAIL PROTECTED]>
---
xkb/xkbEvents.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 151849c..02565a4 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -819,7 +819,8 @@ XkbSrvInfoPtr xkbi;
pXDev = inputInfo.keyboard;
}
-xkbi= pXDev->key->xkbInfo;
+xkbi= (pXDev->key) ? pXDev->key->xkbInfo : NULL;
+
if ( pClient->xkbClientFlags & _XkbClientInitialized ) {
if ((xkbDebugFlags&0x10)&&
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -841,6 +842,10 @@ XkbSrvInfoPtr xkbi;
(_XkbIsReleaseEvent(xE[0].u.u.type)) ) {
return False;
}
+
+if (!xkbi)
+return True;
+
if ((pXDev->deviceGrab.grab != NullGrab)
&& pXDev->deviceGrab.fromPassiveGrab &&
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -884,6 +889,9 @@ XkbSrvInfoPtr xkbi;
else {
register CARD8 type;
+if (!xkbi)
+return True;
+
for (i=0;ihttp://lists.freedesktop.org/mailman/listinfo/xorg
Re: HOWTO for dual-head and ipnut device hotplugging
Dne sreda 26. novembra 2008 je Peter Hutterer napisal(a): > thanks for writing that up. Quick skim left me with two comments: > synaptics fdi: Thanks for your quick proof-reading. It's greatly appreciated :] > don't specify the range unless you really need to. synaptics reads the > range from the kernel and unless the hardware reports false ranges or > you're not happy with the edges, don't specify them. I've removed that now. > "Now you can (and should) safely remove the mouse settings from the > xorg.conf file:" > that particular section wouldn't do anything even if you'd leave it in. It > doesn't have a device option, so it's mute. The side goal of this HOWTO is also to clean up xorg.conf as much as possible, but I removed "(and should)" from that sentance. Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 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: Is it possible to use i810 driver in Xorg7.3 without agpgart kernel module
> Hi All, Hi, > Is it possible to use i810 driver in Xorg7.3 without agpgart kernel module > ? > I use kernel 2.4.31. And It's OK for XFree86 4.6. I think it should work with older versions of the i810 driver, as long the driver recognizes your hardware. Some months ago I worked on something that should be similar to what you are doing, we needed to backport the agpgart kernel module, and i810 XFree86 driver to "certified" linux distros (redhat and conectiva), so that they would work with "today's hardware". > -- > Regards, > > Paul Lin Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/2] xf86-video-intel: i830_driver: drop I830GetRec
There are a number of minor issues w/ I830GetRec:
- pI830 is local, and therefore never gets used
- it only ever returns TRUE (no need to check the result)
- it's only ever called once, so there's not much point in protecting
against multple calls
So, this drops I830GetRec and instead just calls xnfcalloc directly. Since
xnfcalloc will never fail, there's no point in checking the result.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
src/i830_driver.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index 1407a22..a24c8da 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -402,17 +402,6 @@ I830AvailableOptions(int chipid, int busid)
return NULL;
}
-static Bool
-I830GetRec(ScrnInfoPtr pScrn)
-{
- I830Ptr pI830;
-
- if (pScrn->driverPrivate)
- return TRUE;
- pI830 = pScrn->driverPrivate = xnfcalloc(sizeof(I830Rec), 1);
- return TRUE;
-}
-
static void
I830FreeRec(ScrnInfoPtr pScrn)
{
@@ -1755,11 +1744,8 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
if (flags & PROBE_DETECT)
return TRUE;
- /* Allocate driverPrivate */
- if (!I830GetRec(pScrn))
- return FALSE;
+ pI830 = pScrn->driverPrivate = xnfcalloc(sizeof(I830Rec), 1);
- pI830 = I830PTR(pScrn);
pI830->SaveGeneration = -1;
pI830->pEnt = pEnt;
pI830->use_drm_mode = drm_mode_setting;
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 2/2] xf86-video-intel: i810_driver: drop I810GetRec
There aren't as many issues with I810GetRec, but there's not much point
for its existence, either. Since it's only ever called once, drop it
and simply call xnfcalloc directly. Since xnfcalloc will never fail,
there's no point in checking the result.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
src/i810_driver.c | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/src/i810_driver.c b/src/i810_driver.c
index cc28ad8..20d1fe1 100644
--- a/src/i810_driver.c
+++ b/src/i810_driver.c
@@ -528,22 +528,12 @@ i810Setup(pointer module, pointer opts, int *errmaj, int
*errmin)
#ifndef I830_ONLY
/*
- * I810GetRec and I810FreeRec --
+ * I810FreeRec --
*
* Private data for the driver is stored in the screen structure.
- * These two functions create and destroy that private data.
+ * This function destroys that private data.
*
*/
-static Bool
-I810GetRec(ScrnInfoPtr pScrn)
-{
- if (pScrn->driverPrivate)
- return TRUE;
-
- pScrn->driverPrivate = xnfcalloc(sizeof(I810Rec), 1);
- return TRUE;
-}
-
static void
I810FreeRec(ScrnInfoPtr pScrn)
{
@@ -921,11 +911,7 @@ I810PreInit(ScrnInfoPtr pScrn, int flags)
if (pScrn->numEntities != 1)
return FALSE;
- /* Allocate driverPrivate */
- if (!I810GetRec(pScrn))
- return FALSE;
-
- pI810 = I810PTR(pScrn);
+ pI810 = pScrn->driverPrivate = xnfcalloc(sizeof(I810Rec), 1);
pI810->pEnt = xf86GetEntityInfo(pScrn->entityList[0]);
if (pI810->pEnt->location.type != BUS_PCI)
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xf86-video-geode: DCON: set the default (physical) screen size if we detect a DCON
We can be assured that a DCON device has an OLPC panel that's 152x114 mm.
This adds fields to GeodeRec to allow other panels to potentially
override physical width/height fields, and also allows xorg.conf to
override the values.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
src/geode.h |2 ++
src/geode_dcon.c |6 ++
src/lx_output.c | 11 +++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/src/geode.h b/src/geode.h
index e748ec6..37bee2e 100644
--- a/src/geode.h
+++ b/src/geode.h
@@ -196,6 +196,8 @@ typedef struct _geodeRec
Bool tryCompression;
Bool tryHWCursor;
+int mm_width, mm_height; /* physical display size */
+
unsigned long CursorStartOffset;
int Pitch;/* display FB pitch */
diff --git a/src/geode_dcon.c b/src/geode_dcon.c
index 0baa178..13e5fd2 100644
--- a/src/geode_dcon.c
+++ b/src/geode_dcon.c
@@ -92,6 +92,9 @@ dcon_init(ScrnInfoPtr pScrni)
{
GeodeRec *pGeode = GEODEPTR(pScrni);
+pGeode->mm_width = 0;
+pGeode->mm_height = 0;
+
if (!dcon_present()) {
xf86DrvMsg(pScrni->scrnIndex, X_DEFAULT, "No DCON is present\n");
return FALSE;
@@ -115,6 +118,9 @@ dcon_init(ScrnInfoPtr pScrni)
pGeode->panelMode->VTotal = 912;
pGeode->panelMode->Flags = V_NHSYNC | V_NVSYNC;
+pGeode->mm_width = 152;
+pGeode->mm_height = 114;
+
xf86SetModeDefaultName(pGeode->panelMode);
/* TODO: Print board revision once sysfs exports it. */
diff --git a/src/lx_output.c b/src/lx_output.c
index 53a538a..5508477 100644
--- a/src/lx_output.c
+++ b/src/lx_output.c
@@ -249,6 +249,7 @@ LXSetupOutput(ScrnInfoPtr pScrni)
{
xf86OutputPtr output;
LXOutputPrivatePtr lxpriv;
+GeodePtr pGeode = GEODEPTR(pScrni);
output = xf86OutputCreate(pScrni, &lx_output_funcs, "default");
@@ -267,6 +268,16 @@ LXSetupOutput(ScrnInfoPtr pScrni)
GeodeI2CInit(pScrni, &lxpriv->pDDCBus, "CS5536 DDC");
+if (pScrni->monitor->widthmm && pScrni->monitor->heightmm) {
+ /* prioritize the admin's screen size */
+ output->mm_width = pScrni->monitor->widthmm;
+ output->mm_height = pScrni->monitor->heightmm;
+} else if (pGeode->mm_width && pGeode->mm_height) {
+ /* if we have a panel that we're certain of the size of, set it */
+ output->mm_width = pScrni->monitor->widthmm = pGeode->mm_width;
+ output->mm_height = pScrni->monitor->heightmm = pGeode->mm_height;
+}
+
/* We only have one CRTC, and this output is tied to it */
output->possible_crtcs = 1;
}
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
