Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
Hello. I have a Silicon Motion SM720 Lynx3DM card which X in Ubuntu 8.10 (and Fedora 9) will not start on. The log seems fine but ends with: AddScreen/ScreenInit failed for driver 0 The issue it experience seems to have been introduced by changes to X to use libpciaccess. Using GDB, and modified source littered with print statements, I see that it is failing like so: Xorg's dix/main.c's main() calls AddScreen(), which calls (*pfnInit)(...) pfnInit points to Silicon Motion's smi_driver.c's SMI_ScreenInit. SMI_ScreenInit calls SMI_MapMem(). SMI_MapMem calls libpciaccess's common_interface.c's pci_device_map_range(). It finds that the range that wants mapping is already mapped, and everything falls apart. The only other time pci_device_map_range() is called (and indeed for the same region) is earlier when dix.main.c's main() calls InitOutput(), InitOutput() called xf86Screen[0]->PreInit(...). PreInit pointed to Silicon Motion's smi_driver.c's SMI_PreInit() and SMI_PreInit calls SMI_MapMem (which maps the same region as later via pci_device_map_range()). So, I'm going to try and find out what the correct behaviour should be to fix it, but any hints would be gratefully appreciated. I've filed bug #18816 (https://bugs.freedesktop.org/show_bug.cgi?id=18816) with regard to this. Cheers, Richard Schwarting. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 08:19, David Miller a écrit : > But what I spend most of my time doing is figuring out what new > "default" breaks Xorg on my system. This was one of them. > > The other one was the internal fonts stuff with the X server, which > caused me to lose my Emacs international fonts. I don't think it's fair to complain that xorg folks finally started de-emphasizing (not even disabling) the core fonts system more than half a decade after fontconfig was announced and clearly positioned as the target font system (IIRC even SUN was told in no incertain terms it could forget its own next-gen font system because everyone that mattered had adopted fontconfig). If someone complained today foo was only possible in a 2.6 (not 2.4) kernel would you heed it? fontconfig is at least as old as Linux 2.6.0. If you want to complain at someone, complain at software providers which have waited till software started to break user-side to consider the fontconfig transition. Ironically fontconfig was adopted in large part because the core fonts system had major problems with internationalization. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Twas brillig at 11:38:21 01.12.2008 UTC+05 when [EMAIL PROTECTED] did gyre and gimble: AEP> Then it may be a good idea to write such client (even without the pop-up, AEP> a static default stored in the configuration file will also work) and add AEP> it to xorg-apps as an example implementation of such service. Go for it! The problem is more general: there are "desktop" services which don't have good policy clients beside the ones tied to major DEs: Bluetooth, NetworkManager, HAL come to mind. They all need a Unix-style clients to be written, so those who don't use DE may easily configure the corresponding services. IIRC there is CLI NetworkManager client in the works, but rest is still not covered. -- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, Dec 01, 2008 at 09:49:29AM +0100, Nicolas Mailhot wrote: > IIRC even SUN was told in no incertain terms > it could forget its own next-gen font system because everyone that > mattered had adopted fontconfig I may be completely wrong on this one, but ISTR one of the problems with STSF (aside from near-universal[0] adoption of client-side fonts) was that there was pretty much no difference between the size of the actual font, and the size of the metric information you needed to transfer from server to client, anyway. Cheers, Daniel [0]: Emacs in 'utter luddites' shock. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Twas brillig at 20:22:30 01.12.2008 UTC+11 when [EMAIL PROTECTED] did gyre and gimble: DS> [0]: Emacs in 'utter luddites' shock. Not anymore. -- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keysyms: HomePage vs WWW
> "Sergey" == Sergey Udaltsov <[EMAIL PROTECTED]> writes: >> If keyboards which use with the kbd driver generate in >> evdev I'd make be WWW and if they generate when using evdev >> then HomePage. Sergey> Ghm. How could I find this out without having that particular keyboard Sergey> in front of me?;) I suspect WWW is more likely than HomePage. But I see that some of the keyboards have both, often with as HomePage and something else as WWW. And a look through the two drivers and Linux's usb and at kbd drivers didn't make obvious the relationship between evdev codes and what kbd gets from the kernel Maybe the bsd src for converting from usb to their kbd driver might make it easier to predict what code kbd would see from a given usb hid code? -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
From: "Nicolas Mailhot" <[EMAIL PROTECTED]> Date: Mon, 1 Dec 2008 09:49:29 +0100 (CET) > Ironically fontconfig was adopted in large part because the core fonts > system had major problems with internationalization. Ironically you didn't read my posting. I'm not against any of this stuff, I'm against it being done by default which breaks things on existing systems that try to build GIT xorg and help you guys test things. Distribution folks can be educated on what configure knobs to change. And after some time and things settle, the defaults can change. You can say fontconfig had been around long enough, but if something as simple as emacs internationationalized fonts broke, it's obviously not been around long enough to safely change the default. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xrandr does not support screen size across two screens
On Sat, Nov 29, 2008 at 14:53:54 +, Tobias Kaminsky wrote: > > I don't know any details about Xephyr, but the current stable release > > of the Xserver doesn't allow multihead accross multiple graphic > > adapters. This is a planned feature of Xserver 1.6. > > But I am using X across two screens with 2 graphic adapters? > Even mplayer is showing a video across both screens. > > Or do you mean something else? Maybe you use Xinerama insteead of RandR? Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Using XTestFakeDeviceMotionEvent().
> "Chris" == Chris Ball <[EMAIL PROTECTED]> writes: Chris> The following program (requires XInput2) warps my pointer to (0,0) Chris> instead of the requested (600,400). I'd be interested to know whether Chris> this happens for other people, It warped my pointer to 600,400. My server and client libs are all from git (master branches), x86 (32bit). -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Sun, 2008-11-30 at 14:11 +, Beso wrote: > just look at the > evdev driver. i think that after its development > the usability of keyboards and mouses has increased quite a lot. now i > cannot see a reason to switch back to kbd + > mouse instead of evdev. I see one: keyboard layout isn't recognized nor easily configured, so at login screen you're stuck with a qwerty keyboard. Otherwise it's perfect. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 10:39, David Miller a écrit : > > From: "Nicolas Mailhot" <[EMAIL PROTECTED]> > Date: Mon, 1 Dec 2008 09:49:29 +0100 (CET) > >> Ironically fontconfig was adopted in large part because the core >> fonts >> system had major problems with internationalization. > > Ironically you didn't read my posting. > > I'm not against any of this stuff, I'm against it being > done by default which breaks things on existing systems > that try to build GIT xorg and help you guys test things. People have waited more than 5 years to make a change in defaults. Be reasonable and admit this is not an hasty change and software had plenty of time to adapt. > Distribution folks can be educated on what configure knobs > to change. And after some time and things settle, The things have settled years ago. Even Solaris-side. > the defaults can change. Which is what happened here. > You can say fontconfig had been around long enough, but if something > as simple as emacs internationationalized fonts broke, it's obviously > not been around long enough to safely change the default. Emacs is about the only FLOSS software that breaks, and only if you don't run the latest versions. xorg people did emacs folks the courtesy of waiting till they had something working even though pretty much everyone else had switched years before. If there is somethign obvious here, is that emacs maintainers didn't made due diligence by any reasonable definition. Even the kernel made major changes (devfs, sysfs, etc) in the time it took for emacs folks to admit there was a problem. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keysyms: HomePage vs WWW
> I suspect WWW is more likely than HomePage. Yes, I suspect the same thing. That's why I asked. > But I see that some of the keyboards have both, often with as > HomePage and something else as WWW. Yes, for those cases we have to distinguish... > Maybe the bsd src for converting from usb to their kbd driver might make > it easier to predict what code kbd would see from a given usb hid code? Well, I'll try to look at it... Thanks for the idea. Sergey ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, Dec 01, 2008 at 01:39:32AM -0800, David Miller wrote: > From: "Nicolas Mailhot" <[EMAIL PROTECTED]> > Date: Mon, 1 Dec 2008 09:49:29 +0100 (CET) > > > Ironically fontconfig was adopted in large part because the core fonts > > system had major problems with internationalization. > > Ironically you didn't read my posting. Ironically, you didn't read the threads about it. If you did, you'd see that it was done to reduce the fragility of the build and indeed to make life easier for the people who often hit this as one of the first problems, to the point where it was an FAQ though. I guess the term irony is thrown around too easily. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
From: "Nicolas Mailhot" <[EMAIL PROTECTED]> Date: Mon, 1 Dec 2008 10:58:17 +0100 (CET) > If there is somethign obvious here, is that emacs maintainers didn't > made due diligence by any reasonable definition. Even the kernel made > major changes (devfs, sysfs, etc) in the time it took for emacs folks > to admit there was a problem. You can run binaries compiled 15 years ago for Linux and they work and run just fine on today's kernels. Yet my emacs fonts are fux0red, my input device specifications in my xorg.conf file are completely ignored, and MetaSendsEscape no longer works with my xterms, with the current X server. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
From: Daniel Stone <[EMAIL PROTECTED]> Date: Mon, 1 Dec 2008 21:05:46 +1100 > On Mon, Dec 01, 2008 at 01:39:32AM -0800, David Miller wrote: > > From: "Nicolas Mailhot" <[EMAIL PROTECTED]> > > Date: Mon, 1 Dec 2008 09:49:29 +0100 (CET) > > > > > Ironically fontconfig was adopted in large part because the core fonts > > > system had major problems with internationalization. > > > > Ironically you didn't read my posting. > > Ironically, you didn't read the threads about it. If you did, you'd > see that it was done to reduce the fragility of the build and indeed to > make life easier for the people who often hit this as one of the first > problems, to the point where it was an FAQ though. > > I guess the term irony is thrown around too easily. I did read it. It's about people who are unhappy with a new HAL input layer default. A default that, btw, anti-socially totally ignores what people put into their xorg.conf file unless they add yet another knob. That's worse than a default change. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 11:19, David Miller a écrit : > > From: "Nicolas Mailhot" <[EMAIL PROTECTED]> > Date: Mon, 1 Dec 2008 10:58:17 +0100 (CET) > >> If there is somethign obvious here, is that emacs maintainers didn't >> made due diligence by any reasonable definition. Even the kernel >> made >> major changes (devfs, sysfs, etc) in the time it took for emacs >> folks >> to admit there was a problem. > > You can run binaries compiled 15 years ago for Linux and they > work and run just fine on today's kernels. Yes, sure, tell that to all the people who have OSS-using binaries (not even 15 years old) -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
"Richard Schwarting" <[EMAIL PROTECTED]> writes: > Hello. > > I have a Silicon Motion SM720 Lynx3DM card which X in Ubuntu 8.10 (and > Fedora 9) will not start on. The log seems fine but ends with: > AddScreen/ScreenInit failed for driver 0 > > The issue it experience seems to have been introduced by changes to X > to use libpciaccess. > > Using GDB, and modified source littered with print statements, I see > that it is failing like so: > > Xorg's dix/main.c's main() calls AddScreen(), which calls (*pfnInit)(...) > pfnInit points to Silicon Motion's smi_driver.c's SMI_ScreenInit. > SMI_ScreenInit calls SMI_MapMem(). > SMI_MapMem calls libpciaccess's common_interface.c's pci_device_map_range(). > It finds that the range that wants mapping is already mapped, and > everything falls apart. > > The only other time pci_device_map_range() is called (and indeed for > the same region) is earlier when > dix.main.c's main() calls InitOutput(), > InitOutput() called xf86Screen[0]->PreInit(...). > PreInit pointed to Silicon Motion's smi_driver.c's SMI_PreInit() > and SMI_PreInit calls SMI_MapMem (which maps the same region as later > via pci_device_map_range()). > > So, I'm going to try and find out what the correct behaviour should be > to fix it, but any hints would be gratefully appreciated. > > I've filed bug #18816 > (https://bugs.freedesktop.org/show_bug.cgi?id=18816) with regard to > this. > > Cheers, > Richard Schwarting. > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg Hi, Have you tried the driver version from the git repository? I think I fixed this issue on commit c0447d33c82829248e642b3156fd9a3c0d0eb709. Thanks. pgpJ6q8KKGS8i.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
From: "Nicolas Mailhot" <[EMAIL PROTECTED]> Date: Mon, 1 Dec 2008 11:26:51 +0100 (CET) > > > Le Lun 1 décembre 2008 11:19, David Miller a écrit : > > > > From: "Nicolas Mailhot" <[EMAIL PROTECTED]> > > Date: Mon, 1 Dec 2008 10:58:17 +0100 (CET) > > > >> If there is somethign obvious here, is that emacs maintainers didn't > >> made due diligence by any reasonable definition. Even the kernel > >> made > >> major changes (devfs, sysfs, etc) in the time it took for emacs > >> folks > >> to admit there was a problem. > > > > You can run binaries compiled 15 years ago for Linux and they > > work and run just fine on today's kernels. > > Yes, sure, tell that to all the people who have OSS-using binaries > (not even 15 years old) That's a bug that should be fixed and not intentional breakage. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Xavier Bestel wrote: > On Sun, 2008-11-30 at 14:11 +, Beso wrote: >> just look at the >> evdev driver. i think that after its development >> the usability of keyboards and mouses has increased quite a lot. now i >> cannot see a reason to switch back to kbd + >> mouse instead of evdev. > > I see one: keyboard layout isn't recognized nor easily configured, so at > login screen you're stuck with a qwerty keyboard. > Otherwise it's perfect. I think the real question here is who is responsible for this. IMO the distro's have to step up to the plate here. Certainly in Mandriva we have configuration tools (drakconf) to manage things in a fairly central way. Other distros use tools provided in Gnome or KDE to do this, but most of these take effect after the DE has started (I could be pretty off-base here so please forgive me if this is perhaps an over simplification). In Mandriva it will be fairly simple to write a tools into our drakconf that would take /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi, copy it to /etc/hal/fdi/policy/10osvendor/ and edit the keymap to the correct local flavour. Our installation wizard already asks the necessary questions and we keep the answer in /etc/sysconfig/keyboard so even upgrades can have the correct file written for them. Is this something that should be left up to distros to do? I don't know. Paulo (PCPA) was talking about an option that could be put in to xorg.conf that would allow setting of the default keymap via an Option in e.g. ServerFlags section. Is this wise or is this just spreading the config around the place (bits of it in HAL, some in xorg.conf). Is it already the case that config is spread around? IMO distros have to shoulder some responsibility here. A recent example has been pulseaudio integration into the desktop. Some distros did very little work here (the Ubuntu LTS was particularly poor IIRC, with the latter version making up for that mistake). At Mandriva, I personally took a lot of time to ensure good integration and I know that RedHat and Debian did likewise. So is this input config stuff something that distro's should be doing in their own way (at least for the default DM stage - DE's can take over after that)? This is a genuinely open question, not one that is "loaded" in one way or another! 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: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 12:22, Colin Guthrie a écrit : > I think the real question here is who is responsible for this. IMHO the core problem is that the Linux kernel console has been left to rot quietly. The main reason evdev/hal does not export a system layout information xorg could use automatically is that layouts on the console are often misconfigured, since: 1. they do not use the layout database where maintenance happens (xkb-config) 2. therefore the optimal layout is often missing console-side, and "good-enough for debugging" qwerty is used 3. even when there is a good layout, there is often no obvious mapping between the console layout name and the xorg layout name. The result is that since there is no single shared layout X and the kernel use, no layout info is exposed by the kernel infrastructure. (and from a functional point of view there is no reason a key should have a different behaviour in X and the console). BTW now that almost all the X userspace has been converted to use fontconfig and modern TrueType/OpenType fonts, I expect the level of attention fonts in legacy bitmap format receive to drop sharply, which will ultimately lead to problems kernel console-side. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Additional NULL (??) layout group with evdev+hal
Hi Peter,
this is regression caused by correction for 14373 (fixed with commit
ae986d1c73d).
I rebuild server removing the coding that copy more than 2 shift level
and more than 2 groups like this:
/* AB..CDE... -> ABABCDE... */
if (groupWidth > 0 && maxSymsPerKey >= 3)
pCore[2] = pCore[0];
if (groupWidth > 1 && maxSymsPerKey >= 4)
pCore[3] = pCore[1];
/* ABABCDE... -> ABABCDECDE */
/* idx = 2 + groupWidth;
while (groupWidth > 2 &&
idx < maxSymsPerKey &&
idx < groupWidth * 2)
{
pCore[idx] = pCore[idx - groupWidth + 2];
idx++;
}
idx = 2 * groupWidth;
if (idx < 4)
idx = 4;
/* 3 or more groups: ABABCDECDEABCDEABCDE
for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
pCore[idx++] = pXKB[n];
*/
}
After installing this patched server the system doesn't generate this
strange 3rd groups any more. :-)
My guess is that keys not available on the keyboard can not have
keytype and thus the number of shift level is unknown thus keys with
more than 2 shift level generate this additional groups.
Cheers,
Thomas
On Wed, Nov 26, 2008 at 1:26 PM, Peter Hutterer
<[EMAIL PROTECTED]> wrote:
> Haven't had time to look at it yet, but can you check with Bug 16105 if that's
> the same. If so, please attach everything to said bug.
>
> My guess is that the xkb->core->xkb conversion breaks somehow again.
>
> Cheers,
> Peter
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keysyms: HomePage vs WWW
Here I published the keycodes used for WWW and HomePage (and VendorHome, just in case): http://spreadsheets.google.com/ccc?key=pCdLapzoHyYYFYQ5pKV3-QA Another suspect keycode: . May be, we just should state that I32 would be for HomePage, I02 would be for WWW?... Of course, this is only for kbd driver (which is nearly deprecated these days, isn't it?;) Sergey On Mon, Dec 1, 2008 at 9:28 AM, James Cloos <[EMAIL PROTECTED]> wrote: >> "Sergey" == Sergey Udaltsov <[EMAIL PROTECTED]> writes: > >>> If keyboards which use with the kbd driver generate in >>> evdev I'd make be WWW and if they generate when using evdev >>> then HomePage. > > Sergey> Ghm. How could I find this out without having that particular keyboard > Sergey> in front of me?;) > > I suspect WWW is more likely than HomePage. > > But I see that some of the keyboards have both, often with as > HomePage and something else as WWW. > > And a look through the two drivers and Linux's usb and at kbd drivers > didn't make obvious the relationship between evdev codes and what kbd > gets from the kernel > > Maybe the bsd src for converting from usb to their kbd driver might make > it easier to predict what code kbd would see from a given usb hid code? > > -JimC > -- > James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 > > > > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
> "David" == David Miller <[EMAIL PROTECTED]> writes: David> Yet my emacs fonts are fux0red, my input device specifications in David> my xorg.conf file are completely ignored, and MetaSendsEscape no David> longer works with my xterms, with the current X server. Using --disable-config-dbus --disable-config-hal when configuring will drop the input mess and use the spec from xorg.conf. I use them and --disable-builtin-fonts. (Builtin-fonts breaks a *lot* more than just Emacs.) I don't know the fix for MetaSendsEscape. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: > As usual, people who care about something are free to maintain it in > good shape, since this is how free software works. What is there to maintain, exactly? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: > BTW now that almost all the X userspace has been converted to use > fontconfig and modern TrueType/OpenType fonts, I expect the level of > attention fonts in legacy bitmap format receive to drop sharply, which > will ultimately lead to problems kernel console-side. And, as usual, the ones of us that hate antialiased fonts at small sizes can go fuck themselves? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:33, Olivier Galibert a écrit : > > On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: >> BTW now that almost all the X userspace has been converted to use >> fontconfig and modern TrueType/OpenType fonts, I expect the level of >> attention fonts in legacy bitmap format receive to drop sharply, >> which >> will ultimately lead to problems kernel console-side. > > And, as usual, the ones of us that hate antialiased fonts at small > sizes can go fuck themselves? As usual, people who care about something are free to maintain it in good shape, since this is how free software works. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:44, Olivier Galibert a écrit : > > On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: >> As usual, people who care about something are free to maintain it in >> good shape, since this is how free software works. > > What is there to maintain, exactly? Fonts are not generated out of thin hair and they need to be updated to keep up with the environment. Environment changes can be changes in encoding standards (unicode is still evolving and even low-level hardware stuff such as USB identifiers uses unicode), changes in font formats (use the same format as everyone else if you want to tap in the common maintenance pool), changes in hardware capabilities (hardware pixel density is not a physical constant and any change there invalidates the existing pool of bitmap fonts). If you think there's nothing to maintain don't complain if maintenance is not done and things break in a few years. Fonts require maintenance just like every other part of the software stack. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> > What is there to maintain, exactly? > > Fonts are not generated out of thin hair and they need to be updated > to keep up with the environment. Only if you keep breaking the environment carelessly. > Environment changes can be changes in encoding standards (unicode is > still evolving and even low-level hardware stuff such as USB > identifiers uses unicode), changes in font formats (use the same And not many USB devices have description strings in linear-B so why does it matter. > format as everyone else if you want to tap in the common maintenance > pool), changes in hardware capabilities (hardware pixel density is not > a physical constant and any change there invalidates the existing pool > of bitmap fonts). All non issues. In case you've not noticed every time you use a vectorised font you turn it into a bitmap to suit a changing variety of hardware and encodings. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 13:59, Alan Cox a écrit : > >> The result is that since there is no single shared layout X and the >> kernel use, no layout info is exposed by the kernel infrastructure. >> (and from a functional point of view there is no reason a key should >> have a different behaviour in X and the console). > > So load the correct keyboard tables. The kernel is not and never has > been > a keyboard layout manager. That is a policy item, and the fact you may > want differing behaviour and policy for different systems means it > needs to stay so. I didn't write the kernel needed to be a layout manager, just that as long as the different bits of userspace (console and xorg) couldn't agree on a common layouting system there would be no chance of the system exposing a setting xorg could just pick at startup. (and exposing a setting is very different from having this setting managed kernel-side) >> BTW now that almost all the X userspace has been converted to use >> fontconfig and modern TrueType/OpenType fonts, I expect the level of >> attention fonts in legacy bitmap format receive to drop sharply, >> which >> will ultimately lead to problems kernel console-side. > > The bitmap fonts don't change so this sounds like complete garbage. Just check the console on any random selection of non-us or uk systems and you'll see the current garbage is the console output. Sure it is not a blocker because all the different encodings agree on the ASCII part, but anything outside the 127 first codepoints has a high probability of being mis-rendered. > Even > if you want a new bitmap font from a monospace truetype one the > complexity of rendering a bitmap font data set is mindnumbing low, > trivial and automatable. The problem is not rendering the font data, it's to get the right font data in the first place. You have not-so-trivial problems like the limited number of glyphs allowed in console fonts, the fact 4:3 15" VGA screens are not manufactured anymore, etc -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, 1 Dec 2008, James Cloos wrote: >> "David" == David Miller <[EMAIL PROTECTED]> writes: > > David> Yet my emacs fonts are fux0red, my input device specifications in > David> my xorg.conf file are completely ignored, and MetaSendsEscape no > David> longer works with my xterms, with the current X server. > > Using --disable-config-dbus --disable-config-hal when configuring will > drop the input mess and use the spec from xorg.conf. > > I use them and --disable-builtin-fonts. (Builtin-fonts breaks a *lot* > more than just Emacs.) > > I don't know the fix for MetaSendsEscape. I'll just have to wait for this problem to be "released", then start repairing things again. (no change from the past 5 years). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:10, Alan Cox a écrit : > All non issues. > > In case you've not noticed every time you use a vectorised font you > turn > it into a bitmap to suit a changing variety of hardware and encodings. In case you've not noticed the so-called kernel console userspace is totally unable right now to turn standard vectorised fonts into bitmaps suiting a changing variety of hardware and encodings, and relies on manually pre-processed bitmap fonts precious few people maintain and adapt to environment changes. The day it gains parity with xorg on this front, I totally agree with you there would not be any problem maintenance-side. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> In case you've not noticed the so-called kernel console userspace is > totally unable right now to turn standard vectorised fonts into > bitmaps suiting a changing variety of hardware and encodings, and > relies on manually pre-processed bitmap fonts precious few people > maintain and adapt to environment changes. Look I really don't give a hoot about your personal font politics, but trying to bring in bogus technical arguments on the assumption that writing a short bit of code to generate bitmap fonts is too hard for people is a bit of a joke. Your other assumptions are crap too. If people need to do the work then the work will be done. Someone will take an hour to zap out the new bitmap fonts and all will be done. > The day it gains parity with xorg on this front In the areas the matter it is far superior to X11. It renders consoles faster, it renders on text only hardware, it renders font based VGA consoles (ie most of them) outside of bitmap mode and it uses comparatively tiny amounts of memory. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> Just check the console on any random selection of non-us or uk systems > and you'll see the current garbage is the console output. Sure it is > not a blocker because all the different encodings agree on the ASCII > part, but anything outside the 127 first codepoints has a high > probability of being mis-rendered. You mean you don't know how to work the console or put it in unicode mode. Diddums. There are things you can't do in character console mode - arabic is quite tricky, most indian languages are a no-go, but the console isn't designed for that so we don't care. > The problem is not rendering the font data, it's to get the right font > data in the first place. You have not-so-trivial problems like the The font data is out there already thank you. As you keep conveniently forgetting X can already render those fonts to bitmaps suitable for such a screen so the problem doesn't exist except in your mind. > limited number of glyphs allowed in console fonts, the fact 4:3 15" > VGA screens are not manufactured anymore, etc Untrue but rather irrelevant really. The font size in VGA consoles is defined by the hardware on the video card. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
James Cloos wrote: > Using --disable-config-dbus --disable-config-hal when configuring will > drop the input mess and use the spec from xorg.conf. Having just experienced this exact issue, I don't think this is correct. The new server flag AllowEmptyInput does two things wrong right now IMO. 1. It does not "flip" it's default when the above configure options are specified 2. If the evdev driver is not installed on the system it does not flip it's default. I could be wrong with the above but, but certainly it's what I experienced when using 1.5.3. 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: [newb] Will xorg still allow non-hal config?
> The result is that since there is no single shared layout X and the > kernel use, no layout info is exposed by the kernel infrastructure. > (and from a functional point of view there is no reason a key should > have a different behaviour in X and the console). So load the correct keyboard tables. The kernel is not and never has been a keyboard layout manager. That is a policy item, and the fact you may want differing behaviour and policy for different systems means it needs to stay so. > > BTW now that almost all the X userspace has been converted to use > fontconfig and modern TrueType/OpenType fonts, I expect the level of > attention fonts in legacy bitmap format receive to drop sharply, which > will ultimately lead to problems kernel console-side. The bitmap fonts don't change so this sounds like complete garbage. Even if you want a new bitmap font from a monospace truetype one the complexity of rendering a bitmap font data set is mindnumbing low, trivial and automatable. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, 1 Dec 2008 13:33:59 +0100 Olivier Galibert <[EMAIL PROTECTED]> wrote: > On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: > > BTW now that almost all the X userspace has been converted to use > > fontconfig and modern TrueType/OpenType fonts, I expect the level of > > attention fonts in legacy bitmap format receive to drop sharply, which > > will ultimately lead to problems kernel console-side. > > And, as usual, the ones of us that hate antialiased fonts at small > sizes can go fuck themselves? Or non-contortionists can simply tell their font renderer not to anti-alias. I seem to remember even Gnome had a button for that. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 02:05:24PM +0100, Nicolas Mailhot wrote: > > > Le Lun 1 décembre 2008 13:44, Olivier Galibert a écrit : > > > > On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: > >> As usual, people who care about something are free to maintain it in > >> good shape, since this is how free software works. > > > > What is there to maintain, exactly? > > Fonts are not generated out of thin hair and they need to be updated > to keep up with the environment. > > Environment changes can be changes in encoding standards (unicode is > still evolving and even low-level hardware stuff such as USB > identifiers uses unicode), The bdf fonts use unicode. > changes in font formats (use the same > format as everyone else if you want to tap in the common maintenance > pool), You plan to change bdf/pcf? > changes in hardware capabilities (hardware pixel density is not > a physical constant and any change there invalidates the existing pool > of bitmap fonts). Bitmaps don't change. A 12pt bitmap font at 100dpi is a 8pt font at 150dpi and a 6pt at 200dpi. > If you think there's nothing to maintain don't complain if maintenance > is not done and things break in a few years. Fonts require maintenance > just like every other part of the software stack. Looking at the git changelog for adobe-100dpi you're way overstating the number of changes. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:27, Alan Cox a écrit : > Look I really don't give a hoot about your personal font politics, but > trying to bring in bogus technical arguments on the assumption that > writing a short bit of code to generate bitmap fonts is too hard for > people is a bit of a joke. Alan, please, I only wrote that something was currently relying on manual maintenance, that the number of people doing this manual maintenance was decreasing, and that the usual result of something needing to be done and not being done is breakage. These are simple facts. It may be that it's easy to write code to replace the current system with something better but this code is not being written right now and thus does not change a bit about the current trend. I'm sorry if stating this offends you. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:31, Alan Cox a écrit : > >> Just check the console on any random selection of non-us or uk >> systems >> and you'll see the current garbage is the console output. Sure it is >> not a blocker because all the different encodings agree on the ASCII >> part, but anything outside the 127 first codepoints has a high >> probability of being mis-rendered. > > You mean you don't know how to work the console or put it in unicode > mode. Diddums. I mean this is broken every Fedora release or so just by applying system updates without any user-level intervention. I don't think that if the problem was so trivial the fine Fedora maintainers would keep on breaking it. > There are things you can't do in character console mode - arabic is > quite > tricky, most indian languages are a no-go, but the console isn't > designed for that so we don't care. I'm quite aware of the specific needs of those scripts thank you very much, right now the breakage extends to simple latin languages (the last one was romanian I think). >> The problem is not rendering the font data, it's to get the right >> font >> data in the first place. You have not-so-trivial problems like the > > The font data is out there already thank you. As you keep conveniently > forgetting X can already render those fonts to bitmaps suitable for > such a screen so the problem doesn't exist except in your mind. If you're saying X is now needed to render the console I think people will object. If you're saying someone could possibly duplicate what X does console-side I don't disagree. However that does not make it a solution one can use today. >> limited number of glyphs allowed in console fonts, the fact 4:3 15" >> VGA screens are not manufactured anymore, etc > > Untrue but rather irrelevant really. The font size in VGA consoles is > defined by the hardware on the video card. And the userspace that loads it which is limited to 512 codepoints right now IIRC. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Le Lun 1 décembre 2008 14:36, Olivier Galibert a écrit : > > On Mon, Dec 01, 2008 at 02:05:24PM +0100, Nicolas Mailhot wrote: >> >> >> Le Lun 1 décembre 2008 13:44, Olivier Galibert a écrit : >> > >> > On Mon, Dec 01, 2008 at 01:40:57PM +0100, Nicolas Mailhot wrote: >> >> As usual, people who care about something are free to maintain it >> in >> >> good shape, since this is how free software works. >> > >> > What is there to maintain, exactly? >> >> Fonts are not generated out of thin hair and they need to be updated >> to keep up with the environment. >> >> Environment changes can be changes in encoding standards (unicode is >> still evolving and even low-level hardware stuff such as USB >> identifiers uses unicode), > > The bdf fonts use unicode. It's one thing to respect an encoding standard it's another to have the data corresponding to all the parts of this standard. One can "use unicode" with a single-glyph font. >> changes in font formats (use the same >> format as everyone else if you want to tap in the common maintenance >> pool), > > You plan to change bdf/pcf? I just observe few people are working on them anymore, because most applications use something else. >> changes in hardware capabilities (hardware pixel density is not >> a physical constant and any change there invalidates the existing >> pool >> of bitmap fonts). > > Bitmaps don't change. A 12pt bitmap font at 100dpi is a 8pt font at > 150dpi and a 6pt at 200dpi. And at 6pt becomes too small to be used by people with average eyesight. >> If you think there's nothing to maintain don't complain if >> maintenance >> is not done and things break in a few years. Fonts require >> maintenance >> just like every other part of the software stack. > > Looking at the git changelog for adobe-100dpi you're way overstating > the number of changes. I said the maintenance was lagging you say there is little maintenance done. We basically agree. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Sun, Nov 30, 2008 at 10:38 PM, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > > It is traditionally the default only in Xorg. If you get a Russian > version of Windows 2000 or XP, Russian will be the default, with the > possibility to switch to English with Alt+Shift. Also, even in the US > version, the keyboard layout is asked for during the installation, and > this becomes the default for all new keyboards. I have a half completed patch to allow you to set the default RMLVO at build time. Then at least you could have a localized build in a controlled manner. I actually think it would be really easy to write a patch to set the default RMLVO at run time, too. It's a single call to XkbSetRulesDflts. However, I don't know exactly where you'd set that. A separate "XKB" xorg.conf section? And the defaults only last until a device is added with different settings and blows away the old ones with XkbSetRulesDflts. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Daniel Stone wrote: > On Mon, Dec 01, 2008 at 10:47:06AM +0500, Alexander E. Patrakov wrote: >> Also, currently, for unconfigured Xorg, such newly-added keyboard gets >> the "us" layout. This is also a hard-coded policy, should we remove it? > > Ignoring both the rhetoric and the fact that neither of the input > maintainers are American (thanks for the assumption, but Peter's an > Austrian living in Australia, and I'm an Australian who's spent the last > couple of years living in Finland), this will be build-time configurable > soon. > >> In fact, I would consider any default other than "completely unusable >> keyboard that doesn't produce any events" a policy. Reason: I want US >> developers eat their own dogfood. > > I was going to write something in reply to this, but then I realised I > have better things to do. Spare us the drama, please. Disclaimer: I'm American. However, I think I'd prefer dog biscuits to dogfood. Have you ever eaten dog biscuits? They're delicious. Anyway... Would a udev analogy be appropriate? udev is a userspace program that manages a very low-level policy for the kernel. It's responsible for setting sensible defaults, but can be fully customized in order to fit the needs of anybody who wants custom layouts. Why userspace? Because policy shouldn't live in the kernel. Why usable defaults? Because customization shouldn't be mandatory. Why use dbus to talk to the rest of userspace? Because, like it or not, dbus is probably the best way to do so. Now, the big difference between HAL and udev is that udev sets its defaults based on LSB. I don't know whether or not LSB has anything to say about keyboard layouts, or what the default keyboard layout should be. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: What is the purpose of HAL?
Am Sonntag, den 30.11.2008, 23:56 +0600 schrieb Mikhail Gusarov: > Twas brillig at 18:45:04 30.11.2008 UTC+01 when [EMAIL PROTECTED] did gyre > and gimble: > > p> Afaict, HAL is a daemon used to handle hotplug/coldplug of hardware > p> devices. How is this different from what, for instance, udev handles > p> them? I'm no expert in these things, but afaik udev is used to dynamically create device nodes (which is important if linux switches to dynamic major / minor allocation). udev is Linux specific. (udev can take some extra actions when devices are hotplugged / coldplugged) hal is a daemon that informs other clients (listening to hal) when devices are cold / hotplugged. it can do other stuff like mounting / unmounting upon client request. (the client doesn't need to be root therefore). Now you could implement the mounting part with udev only, (automatically mount partitions / disks when disk is hotplugged), but then: * unomunting (w/o) root would not be (easily) possible * you have to check the partition type / fs-type before mounting. This means you end up hacking some fat bash script. * with hal, you can set permissions (eg. for FAT fs) so that the user working on the desktop has r/w access to the mountpoint. > > Is this really the right mailing list to ask? Not mentioning that the > answer is available on the HAL homepage (which you apparently did not > check). > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -- Thomas Ilnseher <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Sun, Nov 30, 2008 at 9:38 PM, Daniel Stone <[EMAIL PROTECTED]> wrote: > On Mon, Dec 01, 2008 at 03:24:42PM +1000, Peter Hutterer wrote: >> On Wed, Nov 26, 2008 at 06:28:58AM -0800, Dan Nicholson wrote: >> > So, it turns out that XkbCopyKeymap doesn't quite do what you'd expect, >> > failing to copy a few fields of the XkbDescRec. I'm not sure whether it's >> > appropriate to copy .device_spec from the cached keymap, but it didn't >> > seem to hurt in my testing. >> >> Tbh, I don't know either :) Daniel, any insights? > > I'm not sure why device_spec even _exists_ (except to be able to pass an > XkbSrvInfoPtr instead of a DeviceIntPtr, but honestly, what's the point > in doing that: just pass either a DeviceIntPtr or an XkbDescPtr), so > that's on my xkb-atkins hitlist (ha!). defined should almost certainly > be copied, yeah. `git grep device_spec' seems to show that it's set to XkbUseCoreKbd during XkbAllocKeyboard() and never changed again anywhere else. So, I don't think it matters to copy it in the server. I was reading the xkb-atkins log a couple weeks ago. It looks like a nice diet. :) -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, 2008-12-01 at 12:59 +, Alan Cox wrote: > > The result is that since there is no single shared layout X and the > > kernel use, no layout info is exposed by the kernel infrastructure. > > (and from a functional point of view there is no reason a key should > > have a different behaviour in X and the console). > > So load the correct keyboard tables. The kernel is not and never has been > a keyboard layout manager. That is a policy item, and the fact you may > want differing behaviour and policy for different systems means it needs > to stay so. I don't think it does. Last time I tried, plugging both an azerty and a qwerty keyboard resulted in only one of them having the correct layout. Maybe something in evdev should somehow translate layouts before mixing events together. Or tag keys with a kind of keyboard-dependant cookie to make sense of them afterwards (I thnk there's an ID in the USB protocol for the keyboard layout, but it's not used right now). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGE protocol spec
On Mon, Dec 1, 2008 at 12:15 AM, Peter Hutterer <[EMAIL PROTECTED]> wrote: ... > ┌─── >RRScreenChangeNotify >type: BYTE; always GenericEvent >extension: CARD8; extension offset >sequenceNumber: CARD16 low 16 bits of request seq. number >length: CARD32 time screen was changed >evtype: CARD16 event type > └─── The "RRScreenChangeNotify" looks odd, should it be "GEScreenChangeNotify"? Pat --- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Mon, Dec 01, 2008 at 06:36:32AM -0800, Dan Nicholson wrote: > I was reading the xkb-atkins log a couple weeks ago. It looks like a > nice diet. :) FWIW, this is progressing nicely, except I've currently regressed the case where people can't compile XKB keymaps. Normally I wouldn't really care about this, but the failure mode is the server crashing when a client connects, because PickKeyboard() returns NULL. Oops. Not hugely sure what to do there. Peter? Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Hi, On Mon, Dec 01, 2008 at 01:33:02PM +, Colin Guthrie wrote: > James Cloos wrote: > > Using --disable-config-dbus --disable-config-hal when configuring will > > drop the input mess and use the spec from xorg.conf. > > Having just experienced this exact issue, I don't think this is correct. > > The new server flag AllowEmptyInput does two things wrong right now IMO. > > 1. It does not "flip" it's default when the above configure options are > specified This is fixed now. > 2. If the evdev driver is not installed on the system it does not flip > it's default. Eh, install evdev. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:15:05PM +0100, Nicolas Mailhot wrote: > 1. they do not use the layout database where maintenance happens > (xkb-config) > 2. therefore the optimal layout is often missing console-side, and > "good-enough for debugging" qwerty is used > 3. even when there is a good layout, there is often no obvious mapping > between the console layout name and the xorg layout name. One of the goals behind xkb-atkins is to make cxkb practical to deploy. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 01:27:49PM +, Alan Cox wrote: > Your other assumptions are crap too. If people need to do the work then > the work will be done. Someone will take an hour to zap out the new > bitmap fonts and all will be done. Good, so if someone cares, then they'll stop using xorg@ as their personal Luddite punching bag. O glorious day. > In the areas the matter it is far superior to X11. It renders consoles > faster, it renders on text only hardware, it renders font based VGA > consoles (ie most of them) outside of bitmap mode and it uses > comparatively tiny amounts of memory. I was trying to come up with a rebuttal, but for the second time in a couple of days, failed as the paragraph is actually self-parody. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
2008/12/1 Corbin Simpson <[EMAIL PROTECTED]>: > Would a udev analogy be appropriate? I think, yes. > udev is a userspace program that > manages a very low-level policy for the kernel. It's responsible for setting > sensible defaults, but can be fully customized in order to fit the needs of > anybody who wants custom layouts. No, the default without any rules is root:root, 0660 for every device. > Why userspace? Because policy shouldn't live in the kernel. Agreed. However, why are the major and minor number in sysfs, instead of some equivalent of devfs? Because they are insufficient to create the device correctly from the first try without the policy. I.e., udev creates a device immediately with the correct permissions, instead of chmoding a kernel-created device (leading to -EPERM race). So the analogy goes this way: Kernel creates a directory in /sys, but no usable device node => Xorg registers an input device, but doesn't make it immediately available (e.g., it starts disabled, if there is such notion in Xorg). Udev takes device major & minor numbers from sysfs and permissions from rules, and then creates the device node => daemon gets the device characteristics (e.g., the fact that it has keys) from Xorg, applies some configuration stored in its database, modifies the device settings and then enables the device, so that in no moment it is enabled, but configured incorrectly. > Why usable defaults? Because customization shouldn't be mandatory. Here we disagree. Debian specifically has acknowledged the need for mandatory customization in some cases. Please see debconf(7) about configuration question priorities: lowVery trivial questions that have defaults that will work in the vast majority of cases. medium Normal questions that have reasonable defaults. high Questions that don't have a reasonable default. critical Questions that you really, really need to see (or else). In their installer, the question about the keyboard layout has the medium priority, but only because the question about the installation language (which is of the critical priority) provides the sensible default. > Why use dbus to talk to the rest of userspace? Because, like it or not, dbus > is probably the best way to do so. Agreed. > Now, the big difference between HAL and udev is that udev sets its defaults > based on LSB. I don't know whether or not LSB has anything to say about > keyboard layouts, or what the default keyboard layout should be. Apriori, there is no sensible default keyboard layout. -- Alexander E. Patrakov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> I mean this is broken every Fedora release or so just by applying > system updates without any user-level intervention. I don't think that So file a Fedora bug. > > The font data is out there already thank you. As you keep conveniently > > forgetting X can already render those fonts to bitmaps suitable for > > such a screen so the problem doesn't exist except in your mind. > > If you're saying X is now needed to render the console I think people > will object. Of course not - the majority of Linux systems don't even run X. However for complex languages you probably end up wanting it in user space so you might as well use all the pango and vector font support. Whether you use X as your renderer at that point is just a design trade off. I suspect most PC oriented Linux distributions would go that way. I know the discussions I've had with distributions on these subjects they are thinking X is the user interface full stop, except for debug/things gone wrong. > > Untrue but rather irrelevant really. The font size in VGA consoles is > > defined by the hardware on the video card. > > And the userspace that loads it which is limited to 512 codepoints > right now IIRC. They are limited to 512 because the kernel interface uses 512 because most PC video hardware is limited to 512. It's not exactly hard to fix if necessary. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> I just observe few people are working on them anymore, because most > applications use something else. I see few people working on them because they are not broken and don't need work. Same with the consoles. We get almost no console patches because the kernel consoles do what people need already. That is the joy of not making random incompatible changes every release - the old stuff doesn't need fixing. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, Dec 01, 2008 at 08:47:02PM +0500, Alexander E. Patrakov wrote: > 2008/12/1 Corbin Simpson <[EMAIL PROTECTED]>: > > Now, the big difference between HAL and udev is that udev sets its defaults > > based on LSB. I don't know whether or not LSB has anything to say about > > keyboard layouts, or what the default keyboard layout should be. > > Apriori, there is no sensible default keyboard layout. Yes, there is, and it's called US. This isn't being Anglo-centric or anything, and I'm not going to argue the point. Your analogy about Russian versions of Windows holds true still: Russian distributions can change the default to ru. Everyone's a winner. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : > Apriori, there is no sensible default keyboard layout. There could be if the hardware started advertising what actually painted on its keys (and even then many people would want to override it). Since it does not, you're right. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Mon, Dec 01, 2008 at 03:50:25PM +, Alan Cox wrote: > > If you're saying X is now needed to render the console I think people > > will object. > > Of course not - the majority of Linux systems don't even run X. I can think of two possible responses: a) good, so it's off-topic for xorg@; b) given that we're talking about font rendering, how we talk about Linux systems that actually render fonts? signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Twas brillig at 16:58:42 01.12.2008 UTC+01 when [EMAIL PROTECTED] did gyre and gimble: >> Apriori, there is no sensible default keyboard layout. NM> There could be if the hardware started advertising what actually NM> painted on its keys /me wonders what "Happy Hacking Blank Top" keyboards would advertise in this case :) -- pgpTynhsX5pPG.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
> > Apriori, there is no sensible default keyboard layout. > > Yes, there is, and it's called US. This isn't being Anglo-centric or Which US layout - there are several and then you get all the variants with extra funny buttons for internet etc ? > anything, and I'm not going to argue the point. Your analogy about > Russian versions of Windows holds true still: Russian distributions can > change the default to ru. Everyone's a winner. The keyboard default can be deduced from the locale default in most cases so the problem can be solved far more elegantly than praying the user is in one particularly random mid sized country. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, 2008-12-01 at 16:58 +0100, Nicolas Mailhot wrote: > > Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : > > > Apriori, there is no sensible default keyboard layout. > > There could be if the hardware started advertising what actually > painted on its keys (and even then many people would want to override > it). Since it does not, you're right. I think it does. Some entries in the Microsoft support pages tend to say so, at least: http://support.microsoft.com/kb/280725 http://support.microsoft.com/kb/304614 HTH, Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
> b) given that we're talking about font rendering, how we talk about > Linux systems that actually render fonts? The subset that do: Framebuffer drivers, nanogui, and X (particularly non embedded devices). Kernel side font handling is bitmaps or font tables with the work done by the video card and anything else is best pushed out to user space anyway as a browse of the pango source quickly shows. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, Dec 01, 2008 at 04:11:46PM +, Alan Cox wrote:
> > > Apriori, there is no sensible default keyboard layout.
> >
> > Yes, there is, and it's called US. This isn't being Anglo-centric or
>
> Which US layout - there are several and then you get all the variants
> with extra funny buttons for internet etc ?
It does not matter. At all.
> > anything, and I'm not going to argue the point. Your analogy about
> > Russian versions of Windows holds true still: Russian distributions can
> > change the default to ru. Everyone's a winner.
>
> The keyboard default can be deduced from the locale default in most cases
> so the problem can be solved far more elegantly than praying the user is
> in one particularly random mid sized country.
__ ___ _ _ _ _ _ _ ___
\ \ / / / ___| | __ )| | | |_ _| |_ _| | | |_ _/ ___|
\ V /| _| \___ \ | _ \| | | | | | | | | |_| || |\___ \
| | | |___ ___) | | |_) | |_| | | | | | | _ || | ___) |
|_| |_|/ |/ \___/ |_| |_| |_| |_|___|/
_ ___ _ ___ _ _ _ ___ _ _ _ ___
| | | | / \ / ___| | \ | |/ _ \_ _| | | |_ _| \ | |/ ___| |_ _/ _ \
| |_| | / _ \ \___ \ | \| | | | || | | |_| || || \| | | _| || | | |
| _ |/ ___ \ ___) | | |\ | |_| || | | _ || || |\ | |_| | | || |_| |
|_| |_/_/ \_\/ |_| \_|\___/ |_| |_| |_|___|_| \_|\| |_| \___/
___ ___ _ _ _ __ _ ___ _ _
| _ \ / _ \ \ \ / /_ _|_ _| | | | \ \/ / _ \| _ \ / ___| |_ _| \ | |
| | | | | | | \ \ /\ / / | | | | | |_| | \ / | | | |_) | | _ | || \| |
| |_| | |_| | \ V V / | | | | | _ | / \ |_| | _ <| |_| | | || |\ |
|/ \___/ \_/\_/ |___| |_| |_| |_| /_/\_\___/|_| \_\\| |___|_| \_|
_ _ _ _ _ __ _
|_ _| | | | | | | | | / \ / ___|_ _|
| | | |_| | _| | | | _| / _ \ \___ \ | |
| | | _ | |___ | |___| |___ / ___ \ ___) || |
|_| |_| |_|_| |_|_/_/ \_\/ |_|
signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Using XTestFakeDeviceMotionEvent().
Hi James, > It warped my pointer to 600,400. > My server and client libs are all from git (master branches), x86 > (32bit). Thanks, that's very helpful to hear. I'm also running from GIT master (via jhbuild), but on 64-bit x86 and Fedora 10. Cheers, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] fix CARD* redefinition in xf86-video-intel
On Mon, 2008-11-24 at 17:22 +0100, Rémi Cardona wrote: > Hi all, > > Arjan sent a patch a month ago about this build bug. Basically, > bios_reader.c redefines CARD* which is defined in some versions of > hw/xfree86/ddc/edid.h, but was removed when vdif.h was dropped last year. > > Here's my attempt to fix it, hopefully in a better way (ie, new drivers > should build with older servers). Signed-off-by: Adam Jackson <[EMAIL PROTECTED]> - ajax 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: Frame buffer Changed Event.
On Tue, 2008-11-25 at 10:18 +0800, Leandro Galvez wrote: > Hi Adam, > > Does damage extension have the api to notify if the framebuffer > has already been updated with the data? Need something to notify me if > buffer has already been updated and ready for display so I can send > the data to the actual physical display device. That's what it does, yes. - ajax 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: DeliverPropertyEvent() accessing unallocated memory
On Tue, 2008-11-25 at 12:55 +0100, Matthieu Herrb wrote: > Thanks for the answer. That seems to work indeed. Applied to master. Thanks for testing! - ajax 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 input module binary compatibility across xorg 1.3, 1.4, or 1.5?
Chueh Steel wrote: > Hi, all, > > 1. Is it possible to compiler one X input module so that it could be > binary compatible across xorg 1.3, 1.4 or 1.5? I believe Nvidia does this, but I don't know if they've published how. Due to the API/ABI changes, you would have to have header files available for all the versions, and check at runtime which ABI is offered and use the appropriate structures/functions for that ABI. It would seem that using arrays of function pointers, much like the core server does, would be one simple way of handling this, filling them in at module initialization with pointers to the functions for the correct ABI.It would be a lot of work... -- -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
i915 backlight failure on resume with 2.6.27
You probably remember the system, it's my fujitsu P7120 lifebook with the funny backlight wiring. Previously, suspend/resume was made to work by saving the PCI state including the legacy backlight register setting (and worked just fine when invoked with a hal quirk). On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and relies on the i915 kernel driver. This was perfectly fine, except that the backlight was now being restored to full brightness on resume rather than the setting on resume. The other annoyance was that VT consoles were now lost on resume (switching to them produces a black screen, although switching back to vt7 where X is running is fine). As of the 2.6.27 fedora kernels, the backlight is now off on resume, which is even more annoying. It can be turned on by doing a VT switch, although all the console VTs are still blank, so there looks to be some bug in the i915 driver that crept in between 2.6.26 and 2.6.27. James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xrandr does not support screen size across two screens
On Sunday 30 November 2008 19:50:28 Tino Keitel wrote: > On Sat, Nov 29, 2008 at 14:53:54 +, Tobias Kaminsky wrote: > > > I don't know any details about Xephyr, but the current stable release > > > of the Xserver doesn't allow multihead accross multiple graphic > > > adapters. This is a planned feature of Xserver 1.6. > > > > But I am using X across two screens with 2 graphic adapters? > > Even mplayer is showing a video across both screens. > > > > Or do you mean something else? > > Maybe you use Xinerama insteead of RandR? > > Regards, > Tino Yeah, this is true. I am using Xinerama Option in xorg.conf. So, there is nothing I can do except for waiting that xorg-server-1.6 will be released? Thanks, Tobi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Daniel Stone wrote: > __ ___ _ _ _ _ _ _ ___ > \ \ / / / ___| | __ )| | | |_ _| |_ _| | | |_ _/ ___| > \ V /| _| \___ \ | _ \| | | | | | | | | |_| || |\___ \ > | | | |___ ___) | | |_) | |_| | | | | | | _ || | ___) | > |_| |_|/ |/ \___/ |_| |_| |_| |_|___|/ Ahh so you propose to remove all characters other than underscores, slashes and pipes form the keymap? I like that plan :p 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: [rant] keeping policy in HAL
Daniel Stone wrote: > Hi, > > On Mon, Dec 01, 2008 at 01:33:02PM +, Colin Guthrie wrote: >> James Cloos wrote: >>> Using --disable-config-dbus --disable-config-hal when configuring will >>> drop the input mess and use the spec from xorg.conf. >> Having just experienced this exact issue, I don't think this is correct. >> >> The new server flag AllowEmptyInput does two things wrong right now IMO. >> >> 1. It does not "flip" it's default when the above configure options are >> specified > > This is fixed now. Handy :) >> 2. If the evdev driver is not installed on the system it does not flip >> it's default. > > Eh, install evdev. Yeah I know, but it's a theoretically possible scenario as evdev is shipped separately but it seems to be mandatory for the server to operate OOTB. Just saying that rather than dump the user to an Xsession with no mouse or keyboard (i.e. basically lock them out of their computer!) it should either: a) Bail noisily and not run b) Failover nicely to reverse the AllowEmptyInput default. 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: [rant] keeping policy in HAL
Xavier Bestel wrote: > On Mon, 2008-12-01 at 16:58 +0100, Nicolas Mailhot wrote: >> Le Lun 1 décembre 2008 16:47, Alexander E. Patrakov a écrit : >> >>> Apriori, there is no sensible default keyboard layout. >> There could be if the hardware started advertising what actually >> painted on its keys (and even then many people would want to override >> it). Since it does not, you're right. > > I think it does. Some entries in the Microsoft support pages tend to say > so, at least: > http://support.microsoft.com/kb/280725 > http://support.microsoft.com/kb/304614 The USB specs have layout as an optional field that most vendors don't fill in since it would cost a few cents extra per keyboard to put in dip switches or different PROMs for different layouts, instead of just attaching different keytops.Sun keyboards do, and I think Apple do, since auto-detection was worth the few extra cents for our users, but I don't know of any others that do. (And because Sun keyboards do, on Solaris, we've always had X ask the kernel for the keyboard layout, from either the hardware or the user settings, and use that to set the X keyboard layout. I've been working with our HAL team to have HAL do this as well as we're moving to Xorg 1.5, and it seems to be working for us, but it depends on the Solaris keyboard layout ioctls, so won't be generally useful, other than as proof that something better than "us"-for-everyone is possible.) -- -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
Re: Keysyms: HomePage vs WWW
Sergey Udaltsov wrote: > Of course, this is only for kbd driver (which is nearly deprecated > these days, isn't it?;) Except on non-Linux systems, where kbd is still used since evdev can't be. -- -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
Pend X server 1.6 Beta2 until Dec 1
I've integrated the Xinput changes, but I'm still waiting for the RandR 1.3 panning updates and DRI2 bits. Plus, there was a US holiday over the weekend that shortened my work schedule a bit. So, I'll finish up the Beta2 release tomorrow. For those of you interested in getting bits into the X server for this release, please edit http://wiki.x.org/wiki/Server16Branch and make sure your proposed patches or other comments are noted there. Just posting to this list is not sufficient; I'm starting to lose track of what's been done and what remains to be done. -- [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: Broken X11 After Mandriva Upgrade
On Wed, 2008-11-26 at 23:27 -0200, Paulo César Pereira de Andrade wrote: > Remove the x11-driver-video-sun... packages listed above. They > were being build and installed by default, but they won't work > on a "normal" ix86 computer. Making one wonder why you build them for architectures that do not, and will never, have sbus attached. - ajax 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: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
On Mon, 2008-12-01 at 00:39 -0800, Richard Schwarting wrote: > So, I'm going to try and find out what the correct behaviour should be > to fix it, but any hints would be gratefully appreciated. Other drivers handle this by unmapping memory at the end of PreInit. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXrandr 1.2.91
This is the first beta for libXrandr 1.3. It adds projective transforms and GetScreenResourcesCurrent, panning support is not there yet. Cheers, Julien Adam Jackson (2): Remove RCS tags. Add GetScreenResourcesCurrent Julien Cristau (3): Set attr->pendingNparams in XRRGetCrtcTransform() RRNotify subevents have 'window' at different offsets, the sequel Bump to 1.2.91 Keith Packard (4): Add support for new Transform requests. Support CRTC Transform filters Eliminate inverse matrix from randr transform protocol Set NparamsFilter in XRRGetCrtcTransform return value. Tomas Carnecky (1): RRNotify subevents have 'window' at different offsets. git tag: libXrandr-1.2.91 http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.2.91.tar.bz2 MD5: 431f6d70db30bf8553352956c4d5e125 libXrandr-1.2.91.tar.bz2 SHA1: 59c0768b7ef40469d68a9d13cf77b9e70f5492c2 libXrandr-1.2.91.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.2.91.tar.gz MD5: d2f98bb9f4c67f122df0493d619032e0 libXrandr-1.2.91.tar.gz SHA1: 15c7f7d15731b93f3893cfa9fff8af3805c13e31 libXrandr-1.2.91.tar.gz signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGE protocol spec
On Mon, Dec 01, 2008 at 08:57:16AM -0600, Pat Kane wrote: > On Mon, Dec 1, 2008 at 12:15 AM, Peter Hutterer > <[EMAIL PROTECTED]> wrote: > ... > > ┌─── > >RRScreenChangeNotify > >type: BYTE; always GenericEvent > >extension: CARD8; extension offset > >sequenceNumber: CARD16 low 16 bits of request seq. number > >length: CARD32 time screen was changed > >evtype: CARD16 event type > > └─── > > The "RRScreenChangeNotify" looks odd, should it be "GEScreenChangeNotify"? Oh, copy/paste desaster, sorry. Below is the correct version. ┌─── GenericEvent type: BYTE; always GenericEvent extension: CARD8; extension offset sequenceNumber: CARD16 low 16 bits of request seq. number length: CARD32 length evtype: CARD16 event type └─── Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Tue, Dec 02, 2008 at 02:31:48AM +1100, Daniel Stone wrote: > On Mon, Dec 01, 2008 at 06:36:32AM -0800, Dan Nicholson wrote: > > I was reading the xkb-atkins log a couple weeks ago. It looks like a > > nice diet. :) > > FWIW, this is progressing nicely, except I've currently regressed the > case where people can't compile XKB keymaps. Normally I wouldn't > really care about this, but the failure mode is the server crashing > when a client connects, because PickKeyboard() returns NULL. Oops. > > Not hugely sure what to do there. Peter? Weird. PK should never return NULL, since there's always the VCK and the VCP. Did you pull in ec1d08442f6935? This change enables the core devices before any Xkb* stuff for any other devices is called, maybe side-stepping the problem. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, Dec 01, 2008 at 01:33:02PM +, Colin Guthrie wrote: > 2. If the evdev driver is not installed on the system it does not flip > it's default. Arguably, that's a busted configuration. The standard fdi tells HAL to add input.x11_driver=evdev (on linux systems). If you then deny X the driver you explicitly told it to load, you end up without input devices. Pretty much the same behaviour when you remove mouse/kbd, btw. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
unsubscribe
unsubscribe ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Tue, Dec 02, 2008 at 08:26:32AM +1000, Peter Hutterer wrote: > On Tue, Dec 02, 2008 at 02:31:48AM +1100, Daniel Stone wrote: > > On Mon, Dec 01, 2008 at 06:36:32AM -0800, Dan Nicholson wrote: > > > I was reading the xkb-atkins log a couple weeks ago. It looks like a > > > nice diet. :) > > > > FWIW, this is progressing nicely, except I've currently regressed the > > case where people can't compile XKB keymaps. Normally I wouldn't > > really care about this, but the failure mode is the server crashing > > when a client connects, because PickKeyboard() returns NULL. Oops. > > > > Not hugely sure what to do there. Peter? > > Weird. PK should never return NULL, since there's always the VCK and the VCP. > Did you pull in ec1d08442f6935? This change enables the core devices before > any > Xkb* stuff for any other devices is called, maybe side-stepping the problem. Yes, but InitKeyboardDeviceStruct can fail these days: if there's no XKB data, then we don't have a core keymap to speak of, so it just bombs out. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken X11 After Mandriva Upgrade
Adam Jackson wrote: > On Wed, 2008-11-26 at 23:27 -0200, Paulo César Pereira de Andrade wrote: > >> Remove the x11-driver-video-sun... packages listed above. They >> were being build and installed by default, but they won't work >> on a "normal" ix86 computer. > > Making one wonder why you build them for architectures that do not, and > will never, have sbus attached. Don't look at me. I wasn't working for Mandriva when those started being installed by default. I just changed the rpm specs to not install them on newer versions... But it is good that it can build on x86, so, while it cannot be "executed", compiler warnings can be checked, and one can check for missing symbols (other then the sbus ones). Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Peter Hutterer wrote: > Pretty much the same behaviour when you remove mouse/kbd, btw. Yeah I guess I can't argue with that logic ;) 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: Random X crashes - radeon m 7500
On Sun, Nov 30, 2008 at 1:41 AM, Dave Wood <[EMAIL PROTECTED]> wrote: > In the kast few days I've had quite a few X crashes. I tried to attach > process to gdb but I had some internal errors and locked up my laptop when > I tried to switch back to vt 7. This is a radeon M 7500 > > Is there some way of debugging this without gdbm or does anyone have any > ideas what the cause might be? > > Googling produces some results but they seem to be various and I haven't > found any solution. Do either of the following options help? Option "AccelMethod" "EXA" Option "RenderAccel" "FALSE" > > Here is the end of my xorg log: > > Backtrace: > 0: /usr/bin/X(xf86SigHandler+0x7e) [0x80bf1ee] > 1: [0xe420] > 2: /usr/lib/xorg/modules//libxaa.so [0xb798aded] > 3: /usr/bin/X [0x8168704] > 4: /usr/bin/X(CompositeGlyphs+0x9a) [0x814fd8a] > 5: /usr/bin/X [0x8157648] > 6: /usr/bin/X [0x8152aa5] > 7: /usr/bin/X [0x814620e] > 8: /usr/bin/X(Dispatch+0x2bf) [0x808688f] > 9: /usr/bin/X(main+0x48b) [0x806ddab] > 10: /lib/libc.so.6(__libc_start_main+0xe0) [0xb7d5a390] > 11: /usr/bin/X(FontFileCompleteXLFD+0x20d) [0x806d121] > > Fatal server error: > Caught signal 11. Server aborting Any chance you could get a proper backtrace with gdb? http://wiki.x.org/wiki/Development/Documentation/ServerDebugging Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrandr 1.2.91
Julien Cristau wrote: > This is the first beta for libXrandr 1.3. It adds projective transforms > and GetScreenResourcesCurrent, panning support is not there yet. I presume this needs an updated xrandrproto? 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
X Hangs at "Initializing int10"
Hi all. I'm upgrading from Fedora 6 to Fedora 10. I did a clean install of Fedora 10 and then, as the default X config didn't work, I copied across my old xorg.conf file. Naturally I had to comment out a few lines in that file. Now a word on my setup. I have two screens, one hanging off an nVidia card, and the other on a SiS card. Both of them work just fine under Fedora 6. Anyway, after I did the steps above, I found it didn't work, so I've been trying one screen at a time. The SiS one works (unless I install the proprietary nVidia driver, so I removed that). The nVidia one doesn't work. I've tried the nv driver, the fbdev driver, and the vesa driver, all of which failed, although not always with the same error message. As nv is the one that worked with Fedora 6, that's the way I'd prefer to go (because it should be possible), but I'm open to other solutions. When I try to use the nv driver, the console appears to be hung, but it's still possible to ssh into the machine. The last entry in the log read as follows: (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Video Driver, version 4.1 (II) NV(0): Initializing int10 The last line you see is the last line in the file. I tried the NoInt10 option, and then it seemed to get a lot further, but eventually failed with "Fatal server error: AddScreen/ScreenInit failed for driver 0". The vesa driver failed at the same point. I'll attach my xorg.conf and my X.0.log; any help would be appreciated. I've also asked this question at: http://forums.fedoraforum.org/showthread.php?t=206005 ...but haven't received an answer, so thought I'd ask here too. Thanks all... - | Name: Tim Nelson | Because the Creator is,| | E-mail: [EMAIL PROTECTED]| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK- X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-92.1.10.el5 i686 Current Operating System: Linux rhys.nelson.org.au 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 Build Date: 16 November 2008 08:29:02PM Build ID: xorg-x11-server 1.5.3-5.fc10 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 1 13:04:10 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "single head configuration" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AIGLX" "on" (==) Automatically adding devices (==) Automatically enabling devices (==) Including the default font path catalogue:/etc/X11/fontpath.d,built-ins. (**) FontPath set to: unix/:7100, catalogue:/etc/X11/fontpath.d, built-ins (**) ModulePath set to "/usr/lib/xorg/modules" (**) Extension "Composite" is enabled (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81f4400 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on linux (--) using VT number 7 (--) PCI: ([EMAIL PROTECTED]:0:0) nVidia Corporation NV17 [GeForce4 MX 440] rev 163, Mem @ 0xf000/0, 0xe000/0, 0xe800/0, BIOS @ 0x/131072 (--) PCI:*([EMAIL PROTECTED]:2:0) Silicon Integrated Systems [SiS] 86C326 5598/6326 rev 11, Mem @ 0xf400/0, 0xf300/0, I/O @ 0x9800/0, BIOS @ 0x/65536 (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) "extmod" will be loaded. This was enabled by default and also spec
xset dpms and power management doesn't work with vesa driver
Vesa driver seems to ignore dpms settings and even 'xset dpms force off' won't power off display. Thinkpad T42 with an ATI Radeon M 7500 Slackware 12.0 xorg 7.1 -- Psychiatrists say that one out of four people are mentally ill. Check three friends. If they're OK, you're it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Mon, 2008-12-01 at 01:39 -0800, David Miller wrote: > > I'm not against any of this stuff, I'm against it being > done by default which breaks things on existing systems > that try to build GIT xorg and help you guys test things. In the particular case of --disable-builtin-fonts, I think 'only built-in core fonts or only non-built-in core fonts' is simply not a useful choice. It should use non-built-in fonts as available but fall back to the built-in fonts. -- 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: [rant] keeping policy in HAL
> On Mon, Dec 01, 2008 at 01:33:02PM +, Colin Guthrie wrote: >> 2. If the evdev driver is not installed on the system it does not flip >> it's default. > > Arguably, that's a busted configuration. The standard fdi tells HAL to add > input.x11_driver=evdev (on linux systems). If you then deny X the driver > you > explicitly told it to load, you end up without input devices. There is one problem with hal, that is with the current mini pcs, and related work to have a "fast boot". Needing to have hal up and running before the X Server would be a tough task. One possible solution, that I proposed some time ago (but got no response) would be to add something like an "UDI" option to input devices. So, one could have something like this in his xorg.conf: Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "UDI" "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input" Option "Protocol" "ExplorerPS/2" Option "Device" "/dev/mouse" EndSection Then, the code in config/hal.c:device_added() or somewhere in hw/xfree86/xf86Xinput.c could check that, and if it matches the device that was about to be added, just leave it alone... > Pretty much the same behaviour when you remove mouse/kbd, btw. > > Cheers, > Peter Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Tue, Dec 02, 2008 at 12:49:40AM -0200, Paulo César Pereira de Andrade wrote: > > On Mon, Dec 01, 2008 at 01:33:02PM +, Colin Guthrie wrote: > >> 2. If the evdev driver is not installed on the system it does not flip > >> it's default. > > > > Arguably, that's a busted configuration. The standard fdi tells HAL to add > > input.x11_driver=evdev (on linux systems). If you then deny X the driver > > you > > explicitly told it to load, you end up without input devices. > > There is one problem with hal, that is with the current mini pcs, > and related work to have a "fast boot". Needing to have hal up and > running before the X Server would be a tough task. > > One possible solution, that I proposed some time ago (but got no > response) would be to add something like an "UDI" option to input > devices. So, one could have something like this in his xorg.conf: > > Section "InputDevice" > Identifier "Mouse1" > Driver "mouse" > Option "UDI" > "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input" > Option "Protocol" "ExplorerPS/2" > Option "Device" "/dev/mouse" > EndSection why not just use Option "Device" "/dev/input/by-id/blahblahblah"? > Then, the code in config/hal.c:device_added() or somewhere in > hw/xfree86/xf86Xinput.c could check that, and if it matches the > device that was about to be added, just leave it alone... evdev won't let you add a device with an already known major/minor again. hal won't a device with a known UDI. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[VGA] HW decoder
Dears, Except libxvmc. Does new VGA driver or others support 264 or VC1 hardware decode? BR, Legis ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
>> One possible solution, that I proposed some time ago (but got no >> response) would be to add something like an "UDI" option to input >> devices. So, one could have something like this in his xorg.conf: >> >> Section "InputDevice" >> Identifier "Mouse1" >> Driver "mouse" >> Option "UDI" >> "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input" >> Option "Protocol" "ExplorerPS/2" >> Option "Device" "/dev/mouse" >> EndSection > > why not just use Option "Device" "/dev/input/by-id/blahblahblah"? That could be a better approach. But maybe would still cause confusion, i.e. for example, in the computer I am typing I have /dev/input/mice, /dev/input/mouse0 and /dev/input/event1, all with different major/minor, but referring to the same ps2 mouse. >> Then, the code in config/hal.c:device_added() or somewhere in >> hw/xfree86/xf86Xinput.c could check that, and if it matches the >> device that was about to be added, just leave it alone... > > evdev won't let you add a device with an already known major/minor again. > hal won't a device with a known UDI. But that would also require using the evdev driver, or somehow telling it that other driver is using that major/minor. Other option is to change other drivers to use EVIOCGRAB on the descriptor, but this could cause some race conditions if two drivers tries to manage the same input device. The problem is that hal/dbus consume a lot of time and resources to be functional, and on low profile computers, needing to wait for those being load to be able to use keyboard/mouse may not be a good option. I also have seem reports of a users having problems after the switch to hal/evdev due to not restoring keyboard/mouse after suspend/resume. > Cheers, > Peter Thanks, Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Tue, Dec 02, 2008 at 04:18:36AM -0200, Paulo César Pereira de Andrade wrote: > >> One possible solution, that I proposed some time ago (but got no > >> response) would be to add something like an "UDI" option to input > >> devices. So, one could have something like this in his xorg.conf: > >> > >> Section "InputDevice" > >> Identifier "Mouse1" > >> Driver "mouse" > >> Option "UDI" > >> "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input" > >> Option "Protocol" "ExplorerPS/2" > >> Option "Device" "/dev/mouse" > >> EndSection > > > > why not just use Option "Device" "/dev/input/by-id/blahblahblah"? > > That could be a better approach. But maybe would still cause > confusion, i.e. for example, in the computer I am typing I have > /dev/input/mice, /dev/input/mouse0 and /dev/input/event1, all > with different major/minor, but referring to the same ps2 mouse. /dev/input/mice and /dev/mouse are not your PS/2 mouse. evdev will not (repeat, not) work with either /dev/input/mice or /dev/mouse. I don't think it'll work with /dev/input/mouse0 either. > >> Then, the code in config/hal.c:device_added() or somewhere in > >> hw/xfree86/xf86Xinput.c could check that, and if it matches the > >> device that was about to be added, just leave it alone... > > > > evdev won't let you add a device with an already known major/minor again. > > hal won't a device with a known UDI. > > But that would also require using the evdev driver, or somehow > telling it that other driver is using that major/minor. Well, yes. If you're using HAL, then you're using evdev. If you're using HAL to tell X that you're using another driver, then you're using another driver. Oh yeah, and HAL won't add the same UDI twice. > Other option is to change other drivers to use EVIOCGRAB on the > descriptor, but this could cause some race conditions if two > drivers tries to manage the same input device. > > The problem is that hal/dbus consume a lot of time and resources > to be functional, and on low profile computers, needing to wait for > those being load to be able to use keyboard/mouse may not be a good > option. > > I also have seem reports of a users having problems after the > switch to hal/evdev due to not restoring keyboard/mouse after > suspend/resume. --disable-config-dbus --disable-config-hal signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On Tue, Dec 02, 2008 at 04:18:36AM -0200, Paulo César Pereira de Andrade wrote: > >> One possible solution, that I proposed some time ago (but got no > >> response) would be to add something like an "UDI" option to input > >> devices. So, one could have something like this in his xorg.conf: > >> > >> Section "InputDevice" > >> Identifier "Mouse1" > >> Driver "mouse" > >> Option "UDI" > >> "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input" > >> Option "Protocol" "ExplorerPS/2" > >> Option "Device" "/dev/mouse" > >> EndSection > > > > why not just use Option "Device" "/dev/input/by-id/blahblahblah"? > > That could be a better approach. But maybe would still cause > confusion, i.e. for example, in the computer I am typing I have > /dev/input/mice, /dev/input/mouse0 and /dev/input/event1, all > with different major/minor, but referring to the same ps2 mouse. if you mount /dev/sda1 to /usr, /root and /home it would also cause confusion. You have two options: Don't configure input devices in xorg.conf and let HAL do the job. This is the standard use-case and we've actually gone to some effort to support this even on legacy setups. Configure input devices manually (in which case you'll need to tell the server to not automagically do things for you). The combination of both is just a bad idea unless you know the trickery involved. > >> Then, the code in config/hal.c:device_added() or somewhere in > >> hw/xfree86/xf86Xinput.c could check that, and if it matches the > >> device that was about to be added, just leave it alone... > > > > evdev won't let you add a device with an already known major/minor again. > > hal won't a device with a known UDI. > > But that would also require using the evdev driver, or somehow > telling it that other driver is using that major/minor. I repeat - config/hal won't let you add a device with a known UDI. If you go through HAL, it's fine. > Other option is to change other drivers to use EVIOCGRAB on the > descriptor, but this could cause some race conditions if two > drivers tries to manage the same input device. There's a reason why we don't use EVIOCGRAB anymore, it breaks too many other (in-kernel) things. > The problem is that hal/dbus consume a lot of time and resources > to be functional, and on low profile computers, needing to wait for > those being load to be able to use keyboard/mouse may not be a good > option. Then don't use it and configure the devices manually. kbd/mouse still work, just like in the olden days. > I also have seem reports of a users having problems after the > switch to hal/evdev due to not restoring keyboard/mouse after > suspend/resume. Unless the these problems float past me (i.e. Red Hat or FDO bugzilla), I can't do much about it. Upstream them, I'm really trying to fix input issues as soon as possible. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Hangs at "Initializing int10"
Timothy S. Nelson wrote: > Hi all. I'm upgrading from Fedora 6 to Fedora 10. I did a clean > install of Fedora 10 and then, as the default X config didn't work, I > copied across my old xorg.conf file. Naturally I had to comment out a > few lines in that file. > > Now a word on my setup. I have two screens, one hanging off an > nVidia card, and the other on a SiS card. Both of them work just fine > under Fedora 6. Most of the setups with 2 graphics cards are broken in xserver 1.5.x. > > Anyway, after I did the steps above, I found it didn't work, so I've > been trying one screen at a time. The SiS one works (unless I install > the proprietary nVidia driver, so I removed that). The nVidia one > doesn't work. I've tried the nv driver, the fbdev driver, and the vesa > driver, all of which failed, although not always with the same error > message. As nv is the one that worked with Fedora 6, that's the way I'd > prefer to go (because it should be possible), but I'm open to other > solutions. > > When I try to use the nv driver, the console appears to be hung, but > it's still possible to ssh into the machine. The last entry in the log > read as follows: > > > > (II) Loading /usr/lib/xorg/modules//libint10.so > (II) Module int10: vendor="X.Org Foundation" > compiled for 1.5.3, module version = 1.0.0 > ABI class: X.Org Video Driver, version 4.1 > (II) NV(0): Initializing int10 > Did you remove the SiS card, or make it inactive in the BIOS in some way before trying that, or is it still there as primary card? This is generally caused by the pci_device_read_rom() function in libpciaccess returning wrong data, probably because ROM and memory access to the secondary card were not enabled correctly before accessing it. The int10 code is then looping endlessly in a maze of 0xff. > > > The last line you see is the last line in the file. I tried the > NoInt10 option, and then it seemed to get a lot further, but eventually > failed with "Fatal server error: AddScreen/ScreenInit failed for driver > 0". The vesa driver failed at the same point. > > I'll attach my xorg.conf and my X.0.log; any help would be appreciated. > I'm not sure if Keith is planning to have this fixed in xserver 1.6. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 0/4] xkb core->xkb conversion fixes
Thomas, here's the set of patches that appears to fix the problem. It's a combination of some bugs and insanity in the XKB protocol. Basically, we're required to convert from XKB to core (including the weird replication in ae986d1c73d), but when converting back we're missing vital information and that leaves us up to guesswork. Please try the attached patches, they seem to fix the issue. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/3] xkb: don't replicate past the number of groups we have.
From: Peter Hutterer <[EMAIL PROTECTED]>
---
xkb/xkbUtils.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 313d418..014ddef 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -524,7 +524,7 @@ int maxNumberOfGroups;
*/
if (nGroups == 1)
{
- int idx;
+ int idx, j;
groupWidth = XkbKeyGroupWidth(xkb, key, XkbGroup1Index);
@@ -547,8 +547,9 @@ int maxNumberOfGroups;
if (idx < 4)
idx = 4;
/* 3 or more groups: ABABCDECDEABCDEABCDE */
- for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
- pCore[idx++] = pXKB[n];
+for (j = 3; j <= maxNumberOfGroups; j++)
+for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
+pCore[idx++] = pXKB[n];
}
pXKB+= XkbKeyGroupsWidth(xkb,key);
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xkb: ensure enough symbols for core Group1 replication.
From: Peter Hutterer <[EMAIL PROTECTED]>
A single-group key on a multi-group keyboard has to be replicated across all
three groups (see Section 12.4 of the XKB protocol spec). Ensure that there's
enough symbols available to actually do that.
e.g. a key ABCD on a 3 group keyboard needs to be replicated as ABABCDCDABCD,
hence requiring space for 12 symbols, even if maxSymsPerKey is less than that.
Signed-off-by: Peter Hutterer <[EMAIL PROTECTED]>
---
xkb/xkbUtils.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 6c90756..313d418 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -361,17 +361,19 @@ _X_EXPORT void
XkbUpdateCoreDescription(DeviceIntPtr keybd,Bool resize)
{
register int key,tmp;
-intmaxSymsPerKey,maxKeysPerMod;
+intmaxSymsPerKey,maxKeysPerMod, maxGroup1Width;
intfirst,last,firstCommon,lastCommon;
XkbDescPtr xkb;
KeyClassPtrkeyc;
CARD8 keysPerMod[XkbNumModifiers];
+intmaxNumberOfGroups;
if (!keybd || !keybd->key || !keybd->key->xkbInfo)
return;
xkb= keybd->key->xkbInfo->desc;
keyc= keybd->key;
-maxSymsPerKey= maxKeysPerMod= 0;
+maxSymsPerKey= maxKeysPerMod= maxGroup1Width= 0;
+maxNumberOfGroups = 0;
bzero(keysPerMod,sizeof(keysPerMod));
memcpy(keyc->modifierMap,xkb->map->modmap,xkb->max_key_code+1);
if ((xkb->min_key_code==keyc->curKeySyms.minKeyCode)&&
@@ -419,6 +421,9 @@ CARD8 keysPerMod[XkbNumModifiers];
if ((w=XkbKeyGroupWidth(xkb,key,XkbGroup1Index))<=2)
tmp+= 2;
else tmp+= w + 2;
+/* remember highest G1 width */
+if (w > maxGroup1Width)
+maxGroup1Width = w;
}
if (nGroups>1) {
if (tmp <= 2) {
@@ -436,6 +441,8 @@ CARD8 keysPerMod[XkbNumModifiers];
tmp+= XkbKeyGroupWidth(xkb,key,XkbGroup4Index);
if (tmp>maxSymsPerKey)
maxSymsPerKey= tmp;
+if (nGroups > maxNumberOfGroups)
+ maxNumberOfGroups = nGroups;
}
if (_XkbCoreKeycodeInRange(keyc,key)) {
if (keyc->modifierMap[key]!=0) {
@@ -469,6 +476,14 @@ CARD8 keysPerMod[XkbNumModifiers];
keyc->maxKeysPerModifier= maxKeysPerMod;
if (maxSymsPerKey>0) {
+ /* See Section 12.4 of the XKB Protocol spec. Because of the
+* single-group distribution for multi-group keyboards, we have to
+* have enough symbols for the largest group 1 to replicate across the
+* number of groups on the keyboard. e.g. a single-group key with 4
+* symbols on a keyboard that has 3 groups -> 12 syms per key */
+ if (maxSymsPerKey < maxNumberOfGroups * maxGroup1Width)
+ maxSymsPerKey = maxNumberOfGroups * maxGroup1Width;
+
tmp= maxSymsPerKey*_XkbCoreNumKeys(keyc);
keyc->curKeySyms.map= _XkbTypedRealloc(keyc->curKeySyms.map,tmp,KeySym);
if (keyc->curKeySyms.map==NULL)
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xkb: don't replicate past the number of groups we have.
From: Peter Hutterer <[EMAIL PROTECTED]>
---
xkb/xkbUtils.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 313d418..014ddef 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -524,7 +524,7 @@ int maxNumberOfGroups;
*/
if (nGroups == 1)
{
- int idx;
+ int idx, j;
groupWidth = XkbKeyGroupWidth(xkb, key, XkbGroup1Index);
@@ -547,8 +547,9 @@ int maxNumberOfGroups;
if (idx < 4)
idx = 4;
/* 3 or more groups: ABABCDECDEABCDEABCDE */
- for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
- pCore[idx++] = pXKB[n];
+for (j = 3; j <= maxNumberOfGroups; j++)
+for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
+pCore[idx++] = pXKB[n];
}
pXKB+= XkbKeyGroupsWidth(xkb,key);
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 2/3] xkb: explicitly check for group replication in the core representation.
From: Peter Hutterer <[EMAIL PROTECTED]>
Single-group keys may get replicated amongst all groups. Check explicitly for
this case and squash it down to one group.
Signed-off-by: Peter Hutterer <[EMAIL PROTECTED]>
---
xkb/XKBMisc.c | 82 +++-
1 files changed, 63 insertions(+), 19 deletions(-)
diff --git a/xkb/XKBMisc.c b/xkb/XKBMisc.c
index 0616c7b..c0b1878 100644
--- a/xkb/XKBMisc.c
+++ b/xkb/XKBMisc.c
@@ -56,6 +56,7 @@ register int i;
unsigned int empty;
intnSyms[XkbNumKbdGroups];
intnGroups,tmp,groupsWidth;
+BOOL replicated = FALSE;
/* Section 12.2 of the protocol describes this process in more detail */
/* Step 1: find the # of symbols in the core mapping per group */
@@ -89,27 +90,70 @@ int nGroups,tmp,groupsWidth;
for (i=2;i=map_width)&&
-((protected&(XkbExplicitKeyType3Mask|XkbExplicitKeyType4Mask))==0)) {
+
+/* Special case: if only the first group is explicit, and the symbols
+ * replicate across all groups, then we have a Section 12.4 replication */
+if ((protected & ~XkbExplicitKeyType1Mask) == 0)
+{
+int j, width = nSyms[XkbGroup1Index];
+
+replicated = TRUE;
+
+/* Check ABAB in ABABCDECDEABCDE */
+if ((width > 0 && CORE_SYM(0) != CORE_SYM(2)) ||
+(width > 1 && CORE_SYM(1) != CORE_SYM(3)))
+replicated = FALSE;
+
+/* Check CDECDE in ABABCDECDEABCDE */
+for (i = 2; i < width && replicated; i++)
+{
+if (CORE_SYM(2 + i) != CORE_SYM(i + width))
+replicated = FALSE;
+}
+
+/* Check ABCDE in ABABCDECDEABCDE */
+for (j = 2; replicated &&
+j < XkbNumKbdGroups &&
+map_width >= width * (j + 1); j++)
+{
+for (i = 0; i < width && replicated; i++)
+{
+if (CORE_SYM(((i < 2) ? i : 2 + i)) != CORE_SYM(i + width * j))
+replicated = FALSE;
+}
+}
+}
+
+if (replicated)
+{
+ nSyms[XkbGroup2Index]= 0;
nSyms[XkbGroup3Index]= 0;
nSyms[XkbGroup4Index]= 0;
- nGroups= 2;
-}
-else {
- nGroups= 3;
- for (i=0;i=map_width)&&
+
((protected&(XkbExplicitKeyType3Mask|XkbExplicitKeyType4Mask))==0)) {
+nSyms[XkbGroup3Index]= 0;
+nSyms[XkbGroup4Index]= 0;
+nGroups= 2;
+} else
+{
+nGroups= 3;
+for (i=0;ihttp://lists.freedesktop.org/mailman/listinfo/xorg
