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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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,
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
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
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
31 matches
Mail list logo
