Jan Kasprzak escreveu:
> 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.
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 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 br
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 s
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
> > repe
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
> accu
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 no
> 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
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@;
> 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 alread
> 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
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
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,
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
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 car
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 out
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.
Ala
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
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
> > attent
> 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
> 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 be
> 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 en
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
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
> > 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 ev
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?
Font
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
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 b
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 automa
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 s
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 re
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 un
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?
>
> Ye
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) T
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 a
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
sup
Colin Guthrie wrote:
> eatdirt wrote:
> At the moment, Xorg will automatically disabled kbd/mouse devices unless
> you set the AllowEmptyInput flag in the server.
>
> From the man page:
>
> Option "AllowEmptyInput" "boolean"
>If enabled, don't add the standard keyboard
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
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
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 nee
41 matches
Mail list logo
