From: Zhao Yakui
v1->v2: Make one condition case for one quirk instead of merging them
together. This is based on the Keithp's suggestion.
Move the EDID quirk for Philips LCD LP154W01 as the panel reports the vertical
size in cm.
https://bugs.freedesktop.org/show_bug.cgi?id=24482
Signed-off-by
As with RC1, there's nothing overly exciting about this release, just a
bunch of fixes all over, with XQuartz having a largest batch of changes.
1.7.2 is scheduled for next friday, so please only nominate crucial fixes
now.
Adam Jackson (1):
randr: Fill in errorValue when verifying outputs/c
On Wed, 2009-11-18 at 18:04 +0800, Zhao, Yakui wrote:
> From: Zhao Yakui
>
> Move the EDID quirk for Philips LCD LP154W01 as the panel reports the vertical
> size in cm.
Hi, Keith/Ajax
How about this patch?
The incorrect quirk is applied to Philips LCD(154W01), which causes
that the incorre
Release 0.10.1 of the xf86-input-wacom driver is now available.
Note that this driver currently resides in my $HOME on freedesktop.org.
http://cgit.freedesktop.org/~whot/xf86-input-wacom/
Loads of patches, mostly cleanup and aimed towards better hotplugging
support. Instead of relying on HAL dire
Csillag Kristof wrote:
> This is a FireMV card, which is produced for a relatively narrow market
> segment, so unfortunately, the latest fglrx driver does not seem to
> support it. (I have tried this, of course.)
>
> There is an other proprietary driver for FireMV cards which I have
> downloaded fr
Only three fixes, bug 24737 is a regression from 2.2 and seems to affect a
number of people.
Bartosz Brachaczek (1):
Set all valuators for relative motion events (#24737)
Dmitry Torokhov (1):
Relax checks when reopening devices
Peter Hutterer (2):
Fix drag-lock property handler
On Wed, Nov 18, 2009 at 01:26:10PM +0100, Dirk Wallenstein wrote:
> > what would be the difference to having an additional group that triggers
> > only those "shortcut" keysyms (XF86Back, XF86Forward, XF86Whatnot)?
>
> None. The point of this example together with the example 3 is that I
> would l
On Thu, 2009-11-19 at 20:34 +0100, Dirk wrote:
> On Thursday 19 November 2009 16:48:35 Maciej Piechotka wrote:
>
> > It seems to work but is it possible to do it from xmodmap?
>
> No, xmodmap is a pre-XKB application.
> One possibility is to load the keymap from a script in an autostart
> direct
No, zaphod doesn't work either. This has to be the bridge chip between
the two 2400 radeon chips that is causing the confusion.
On Nov 19, 2009, at 1:05 PM, Alex Deucher wrote:
> On Thu, Nov 19, 2009 at 1:42 PM, Donald Kayser
> wrote:
>> Ok, some progress, I have updated to more recent radeo
On Thu, Nov 19, 2009 at 1:42 PM, Donald Kayser wrote:
> Ok, some progress, I have updated to more recent radeon and xserver.
> It no longer dies on having the second device around. But, I have not
> been able to get the second PCI device to be recognized. I now get the
> following error for the se
Ok, some progress, I have updated to more recent radeon and xserver.
It no longer dies on having the second device around. But, I have not
been able to get the second PCI device to be recognized. I now get the
following error for the second set of monitors on the second pci bus
id. I have t
Hi,
I have a similiar problem with CentOS 5 and the latest xorg packages. I already
compiled the siliconmotion v1.6 against the CentOS 5's xorg base but this
doesn't help.
Do you have an uplink to the mailing list archive issue with the "kernel rom
problem"? I couldn't find it with the Archive
Thank you very much for response. I am sorry for the delay of response -
I don't recive mails from xorg list so please add me to CC next time.
It seems to work but is it possible to do it from xmodmap? I needed to
change 2 entries into FOUR_LEVEL_SEMIALPHABETIC/FOUR_LEVEL_ALPHABETIC
and AFAIK my d
On Thu, Nov 19, 2009 at 3:37 AM, Csillag Kristof
wrote:
> Alex Deucher wrote:
>>>
>>> I there any software work-around I could try to test this hypothesis?
>>>
>>
>> You could try the windows driver or fglrx and see if they exhibit the
>> problem as well.
>>
> This is a FireMV card, which is produ
2009/11/19 Peter Hutterer :
> i don't actually know how evtouch works internally, last time I tried it
> didn't build against 1.7 at which point I lost interest. It doesn't seem to
> be very actively maintained (unless google hides the active upstream from
> me).
When I looked into the touchscreen
Peter,
> i'll attach a simple test program that I've used to debug a few things, I
> just verified it works correctly. (argv[1] must be the pointer ID of the
> master pointer to change).
Thanks a lot, that helped. My code works now, I simply forgot to call
XCloseDisplay/XFlush at the end. I'll att
Alex Deucher wrote:
>>
>> I there any software work-around I could try to test this hypothesis?
>>
>
> You could try the windows driver or fglrx and see if they exhibit the
> problem as well.
>
This is a FireMV card, which is produced for a relatively narrow market
segment, so unfortunately
17 matches
Mail list logo