Re: [newb] Will xorg still allow non-hal config?
Peter Hutterer wrote:
: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html
:
: That's a quick brain dump of input related things I could think of that are
: repeatedly asked on the list, irc, and bugreports. The information is accurate
: as of git master today and extends to server 1.5 (mostly) and server 1.6.
Thanks for the explanation. One question, though:
is there a way of using HAL-managed devices in multi-seat X? If yes,
how can I specify which input device belongs to which seat?
I use static devices in Xorg.conf so far, but I would like
to have it working even after unplugging/replugging the input device.
-Yenya
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ |
If you find yourself arguing with Alan Cox, you’re _probably_ wrong.
--James Morris in How and Why You Should Become a Kernel Hacker
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Wednesday 03 December 2008 09:21:51 pm Peter Hutterer wrote: On Wed, Dec 03, 2008 at 08:08:35PM -0800, vehemens wrote: On Wednesday 03 December 2008 02:33:34 pm Peter Hutterer wrote: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Hate to be a bringer of bad news but The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers. is not correct. the statement is correct. If the keyboard driver doesn't work, please file a bug at bugs.freedesktop.org. Actually that's two statements and the blog doesn't list the first one. I filed a bug so you can correct your blog : By the way, what type of testing are you doing? OS/kernel version(s)? 32 bit and/or 64 bit? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Thu, Dec 04, 2008 at 07:53:32AM -0800, vehemens wrote: By the way, what type of testing are you doing? OS/kernel version(s)? 32 bit and/or 64 bit? Currently: One F10 laptop (1.5.3 + fedora patches), an occasional F9 laptop (1.5.2 + fedora patches), one box running master on Ubuntu (8.04 I think) and one testbox running master and/or 1.6 on F10. All 32 bit, though I should eventually switch the F10 testbox to 64. Kernel versions: whatever comes with the distros on a given day. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Sat, Nov 29, 2008 at 06:37:48PM +0100, eatdirt wrote: sorry about the naive questions, I am a mandriva cooker tester/user, and I have just discovered recently that soon, I'll have to start HAL to get working device under X. So I have a few comments/questions: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? 2) I am not competent to understand the need of HAL under xorg. But I am experienced enough to understand that doing so will increase the probability of X failure by, at least, the one of HAL failure. Why taking such a risk? 3) Does Xorg plan is to become a big unique freedesktop/operating system in itself, sort of windows like? [--- tease :)] http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Wednesday 03 December 2008 02:33:34 pm Peter Hutterer wrote: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Hate to be a bringer of bad news but The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers. is not correct. It faults with git master on my FreeBSD machine. (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) filter chain progression: 2.00 (**) Mouse0: (accel) filter stage 0: 20.00 ms (**) Mouse0: (accel) set acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option CoreKeyboard (**) Keyboard0: always reports core events (**) Option Protocol standard (**) Keyboard0: Protocol: standard (**) Option AutoRepeat 500 30 (**) Option XkbRules xorg (**) Keyboard0: XkbRules: xorg (**) Option XkbModel pc105 (**) Keyboard0: XkbModel: pc105 (**) Option XkbLayout us (**) Keyboard0: XkbLayout: us (**) Option CustomKeycodes off (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) Fatal server error: Caught signal 11. Server aborting ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Wed, Dec 03, 2008 at 08:08:35PM -0800, vehemens wrote: On Wednesday 03 December 2008 02:33:34 pm Peter Hutterer wrote: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Hate to be a bringer of bad news but The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers. is not correct. the statement is correct. If the keyboard driver doesn't work, please file a bug at bugs.freedesktop.org. Cheers, Peter ___ 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: [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: [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: [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: [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: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?
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: [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?
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: [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: [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: [newb] Will xorg still allow non-hal config?
2008/11/29 Colin Guthrie [EMAIL PROTECTED]: eatdirt wrote: Hi all, sorry about the naive questions, I am a mandriva cooker tester/user, and I have just discovered recently that soon, I'll have to start HAL to get working device under X. So I have a few comments/questions: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? Yes. Some platforms that Xorg is on do not support hal. But that said, there are lots of things in Gnome/KDE that just don't work without HAL, so more and more you will need it for correct operation. Is there any reason you have a problem using hal? Amusingly, GNOME is already seeing push to move *away* from HAL: http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00247.html -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Sat 29.Nov'08 at 18:52:55 +, Matthew Garrett wrote: On Sat, Nov 29, 2008 at 06:37:48PM +0100, eatdirt wrote: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? Yes, especially since HAL is not available on all the platforms that X supports. You can still configure devices statically via Xorg.conf. Nice to know about that. I don't need HAL here with my Window Maker and was worried about the news of X requiring HAL in the future. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
2008/11/30 Kalle Vahlman [EMAIL PROTECTED]: 2008/11/29 Colin Guthrie [EMAIL PROTECTED]: eatdirt wrote: Hi all, sorry about the naive questions, I am a mandriva cooker tester/user, and I have just discovered recently that soon, I'll have to start HAL to get working device under X. So I have a few comments/questions: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? Yes. Some platforms that Xorg is on do not support hal. But that said, there are lots of things in Gnome/KDE that just don't work without HAL, so more and more you will need it for correct operation. Is there any reason you have a problem using hal? Amusingly, GNOME is already seeing push to move *away* from HAL: http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00247.html they're just substituting it with devicekit, that does the same thing hal does but it's more modular and scalable. the problem with devicekit is that it's still young and hasn't been really tested in a distro. the first to do so should be fedora 11. well, anyway going with hal or devicekit it's not really important, the fact is that the introduction of these layers for the handling of peripherals give more freedom. 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. this is the same with the other hw info needed by xorg for configuration. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[newb] Will xorg still allow non-hal config?
Hi all, sorry about the naive questions, I am a mandriva cooker tester/user, and I have just discovered recently that soon, I'll have to start HAL to get working device under X. So I have a few comments/questions: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? 2) I am not competent to understand the need of HAL under xorg. But I am experienced enough to understand that doing so will increase the probability of X failure by, at least, the one of HAL failure. Why taking such a risk? 3) Does Xorg plan is to become a big unique freedesktop/operating system in itself, sort of windows like? [--- tease :)] Best, Chris. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
Twas brillig at 18:12:09 29.11.2008 UTC+00 when [EMAIL PROTECTED] did gyre and gimble: CG But that said, there are lots of things in Gnome/KDE that just CG don't work without HAL, so more and more you will need it for CG correct operation. Quoting the first mail: if you are not under the gas factory desktops, gnome/kde CG Is there any reason you have a problem using hal? Well, I personally have a problem that it is quite hard to put reference HAL (and D-Bus!) implementation into the device with 16Mb of RAM, without any swap and only 64Mb of NAND flash, but that's a completely different story. -- pgpIF0xwDoIy5.pgp Description: PGP 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 Sat, Nov 29, 2008 at 10:12 AM, Colin Guthrie [EMAIL PROTECTED] wrote: ?? Xorg is the xserver and related drivers and apps. While this is a critical part of the puzzle I doubt this is anywhere near comparable to what you would call a operating system. In many ways, Xorg sure seems like an operating system kernel when you look at it under the hood; it has a separation of kernel space and user space (server and clients talking via sockets), it has drivers, and it even has its own task scheduling algorithm (!!!). That said, Xorg is moving *away* from being an entire operating system, if anything. There is a push to move most of the drivers into actual kernel space, and some of the work Red Hat is doing seems to push half of the X server into the kernel. (I'm not that familiar with Wayland, so no doubt half of the X server is a gross exaggeration, but my basic point still stands.) -- William Tracy [EMAIL PROTECTED] -- [EMAIL PROTECTED] Vice President, Cal Poly Linux Users' Group http://www.cplug.org I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
