2:30 p.m.
I plan to rebase the X server to git master a week from today (Monday,
November 12), which means the changes should hit rawhide on Tuesday.
DEAR SHORT ATTENTION SPAN PEOPLE:
% sudo sed -i -e '/^\[main\]/ a exclude=xorg-*' /etc/yum.conf
Run that line to opt out of the disaster. Thank you for your time.
Now for some details.
This X server requires libpciaccess. Not all of the drivers have been
ported yet. Not all of them will be ported by Monday, though I'll try
to have the big three of {radeon,intel,nv} and the vesa driver converted
by then. This should cover most people. I hope.
If your driver is not ported, you'll see an error like this in the X
log:
(EE) module ABI major version (1) doesn't match the server's version (3)
This means switch to vesa, or else back down to F8 X.
Mesa will rebase in the same go. This may or may not break 3D for you.
It shouldn't, but it might. Likewise libdrm, but that's unlikely to be
a problem in and of itself. I'm quite likely to update those two
components sometime this week, they should be relatively low impact on
their own.
This server will also introduce input hotplug support. TBH I have no
idea how this should be set up at the moment. I'll try to get something
working at least for the machines I have here, but that might only be
good enough for static configuration same as F8 and earlier. If someone
wants to own the i-h part of this that'd be awesome, otherwise we'll get
to it as we have time.
I think those are the highlights. If there are any further questions,
please ask, I may have missed something. If any bugs come up in the
transition, please do file them! We need to know what breaks so we know
what we need to fix. And of course, all patches and assistance are
greatly appreciated.
- ajax
8:29 a.m.
On 11/05/07 15:30, Adam Jackson wrote:
This server will also introduce input hotplug support. TBH I have
no
idea how this should be set up at the moment. I'll try to get something
working at least for the machines I have here, but that might only be
good enough for static configuration same as F8 and earlier. If someone
wants to own the i-h part of this that'd be awesome, otherwise we'll get
to it as we have time.
Maybe I could help here. I added input hotplug support
for Xserver 1.4 on the OLPC not long ago.
The package changes are not in CVS because I'm still
overwhelmed by other urgent work, but all the srpms are
available for reference here:
http://www.codewiz.org/pub/olpc-bernie/source/
Forgive me stuffing x11-input.fdi in the Xserver package
and installing it to /etc/hal/fdi. That was just a kludge
to avoid modifying hal too.
It took me a while to get i-h right because I had no idea
what was needed, and I was also confused by longstanding
bugs in our kernel drivers, but in retrospect it didn't
take that much tweaking, at least for our fixed platform.
One non trivial change for Fedora would be moving the kbd
config away from xorg.conf. Both Gnome and KDE can already
override the server settings through XKB. The various
display managers, I'm afraid, don't do anything by default.
Same with startx.
The X server also supports receiving XKB configuration from
HAL, and Daniel Stone seems to think that a good design for a
fallback would be writing the default keyboard layout inside
a copy of x11-input.fdi and writing it to /etc/hal/fdi/.
We should also consider adjusting also system-config-keyboard
accordingly.
Also, I'm not sure if this is a good right time to do it, but
we may benefit from switching to evdev for mice and keyboards,
if only to put let that horrible /dev/input/mice and its
emulated PS/2 protocol rest in peace :-)
I think those are the highlights. If there are any further
questions,
please ask, I may have missed something. If any bugs come up in the
transition, please do file them! We need to know what breaks so we know
what we need to fix. And of course, all patches and assistance are
greatly appreciated.
That's great work. I'm Looking forward to see it landing on
rawhide!
My only rawhide machine is a G4 laptop at home, and my time
to contribute is very limited. So I can't do much more
than testing and answering questions on IRC.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
9:24 a.m.
On Tue, 2007-11-06 at 09:29 -0500, Bernardo Innocenti wrote:
One non trivial change for Fedora would be moving the kbd
config away from xorg.conf. Both Gnome and KDE can already
override the server settings through XKB. The various
display managers, I'm afraid, don't do anything by default.
Same with startx.
This will change soon for gdm, I think. The gdm rewrite will make it
possible to have a keyboard layout selector on the login screen, very
similar to what you have inside the session. At least that is one of the
goals.
Also, I'm not sure if this is a good right time to do it, but
we may benefit from switching to evdev for mice and keyboards,
if only to put let that horrible /dev/input/mice and its
emulated PS/2 protocol rest in peace :-)
Switching to evdev is also planned for F9, and will probably be part of
the "big breakage".
12:04 p.m.
On Tue, 2007-11-06 at 10:24 -0500, Matthias Clasen wrote:
On Tue, 2007-11-06 at 09:29 -0500, Bernardo Innocenti wrote:
> One non trivial change for Fedora would be moving the kbd
> config away from xorg.conf. Both Gnome and KDE can already
> override the server settings through XKB. The various
> display managers, I'm afraid, don't do anything by default.
> Same with startx.
This will change soon for gdm, I think. The gdm rewrite will make it
possible to have a keyboard layout selector on the login screen, very
similar to what you have inside the session. At least that is one of the
goals.
Why is that functionality being added to a desktop manager? What exactly
is the definition for a desktop manager these days? I've always found
the name "desktop manager" to be a bit misleading. In my mind, I've
always thought of it as just a user login system (determining the user
for a session). Are desktop managers supposed to handle more than that?
--
Richi Plana
12:19 p.m.
On 11/6/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
Why is that functionality being added to a desktop manager? What
exactly
is the definition for a desktop manager these days? I've always found
the name "desktop manager" to be a bit misleading. In my mind, I've
always thought of it as just a user login system (determining the user
for a session). Are desktop managers supposed to handle more than that?
rpm -qi gdm
Gdm (the GNOME Display Manager)
gdm makes it possible for you to login to the system. Let's avoid
trying to shoe-horn what that means into legacy concepts like
"desktop."
There are absolutely real situations where a computer will have
multi-lingual users. Wouldn't it be great if those users could have
their native keyboard layout at the login screen for login names and
passwords.
-jef"Semantical games are my chosen blood sport"spaleta
12:34 p.m.
On 11/6/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 11/6/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> Why is that functionality being added to a desktop manager? What exactly
> is the definition for a desktop manager these days? I've always found
There are absolutely real situations where a computer will have
multi-lingual users. Wouldn't it be great if those users could have
their native keyboard layout at the login screen for login names and
passwords.
+1
Some people also use dvorak. Typing in my password in Qwerty is hard
enough, but when I've physically remapped my keyboard, remembering
Qwerty just to type in a password (let alone what happens when I need
to play with GRUB) is a huge pain in the rear.
-Yaakov
12:40 p.m.
On 11/6/07, Yaakov Nemoy <loupgaroublond(a)gmail.com> wrote:
Some people also use dvorak.
It's important that we make the effort to make using Fedora easier for
those with diagnosed mental impairments...even dvorak users.
-jef"has a theory.. that there is a high correlation between esperanto
speakers and dvorak users"spaleta
1:18 p.m.
On Tue, 2007-11-06 at 09:19 -0900, Jeff Spaleta wrote:
On 11/6/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> Why is that functionality being added to a desktop manager? What exactly
> is the definition for a desktop manager these days? I've always found
> the name "desktop manager" to be a bit misleading. In my mind, I've
> always thought of it as just a user login system (determining the user
> for a session). Are desktop managers supposed to handle more than that?
rpm -qi gdm
Gdm (the GNOME Display Manager)
gdm makes it possible for you to login to the system. Let's avoid
trying to shoe-horn what that means into legacy concepts like
"desktop."
There are absolutely real situations where a computer will have
multi-lingual users. Wouldn't it be great if those users could have
their native keyboard layout at the login screen for login names and
passwords.
"Shoe-horning gdm into a legacy concept" wasn't my intention. Just
making sure that features are in their rightful place to avoid
duplication of (and possibly conflicting) effort.
"gdm makes it possible for you to login to the system" is exactly what I
had in mind for gdm (and other "deskop managers", or "display
manager"
in the case of gdm). If having the wrong keyboard type makes it
impossible to log in, then yes, I do agree that lacking that, by
definition, would mean a failure in the system. Me, I'm just trying to
understand the logic behind it (not saying there isn't any or it's
wrong).
Semantics is good. As a firm believer in Agile Modeling concepts, I
agree with the tenet "Your goal is to build a shared understanding, it
isn't to write detailed documentation."
--
Richi Plana
1:10 p.m.
On Tue, 06 Nov 2007 11:04:09 -0700
Richi Plana <myfedora(a)richip.dhs.org> wrote:
Why is that functionality being added to a desktop manager? What
exactly is the definition for a desktop manager these days? I've
always found the name "desktop manager" to be a bit misleading. In my
mind, I've always thought of it as just a user login system
(determining the user for a session). Are desktop managers supposed
to handle more than that?
What if you need to use your native layout in order to type in your
username correctly, or password due to muscle memory.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
12:14 p.m.
Richi Plana <myfedora(a)richip.dhs.org> wrote:
> Why is that functionality being added to a desktop manager? What
> exactly is the definition for a desktop manager these days? I've
> always found the name "desktop manager" to be a bit misleading. In my
> mind, I've always thought of it as just a user login system
> (determining the user for a session). Are desktop managers supposed
> to handle more than that?
What if you need to use your native layout in order to type in your
username correctly, or password due to muscle memory.
This is important for the auto config with no x.org file as when i use
no config with the intel drivers i get a US layout not the expected UK
layout. See bug from a while ago here
https://bugzilla.redhat.com/show_bug.cgi?id=252319
Peter
5:16 p.m.
On 11/06/07 10:24, Matthias Clasen wrote:
This will change soon for gdm, I think. The gdm rewrite will make it
possible to have a keyboard layout selector on the login screen, very
similar to what you have inside the session. At least that is one of the
goals.
Where does it read the defaults from? It has to be a file
easily editable from system-config-keyboard.
Maybe we could just augment /etc/sysconfig/keyboard?
Switching to evdev is also planned for F9, and will probably be part
of
the "big breakage".
Ah, cool! Who's doing this work? I'd like to resync
my OLPC packaging work if possible.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
6:17 p.m.
On Tue, 2007-11-06 at 18:16 -0500, Bernardo Innocenti wrote:
On 11/06/07 10:24, Matthias Clasen wrote:
> This will change soon for gdm, I think. The gdm rewrite will make it
> possible to have a keyboard layout selector on the login screen, very
> similar to what you have inside the session. At least that is one of the
> goals.
Where does it read the defaults from? It has to be a file
easily editable from system-config-keyboard.
The gconf database of the gdm user, I think. It is debatable if that is
easily editable from system-config-keyboard and if it should. Why do you
think that would be necessary ?
> Switching to evdev is also planned for F9, and will probably be
part of
> the "big breakage".
Ah, cool! Who's doing this work? I'd like to resync
my OLPC packaging work if possible.
The X guys.
5:32 p.m.
On 11/6/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
This will change soon for gdm, I think. The gdm rewrite will make it
possible to have a keyboard layout selector on the login screen, very
similar to what you have inside the session. At least that is one of the
goals.
Would it be possible for gdm to know what each user prefers as a
keyboard layout?
Like if I use the face browser and select a user foo with the mouse.
Can gdm know user foo's default keyboard layout and use it for the
password entry?
-jef
6:14 p.m.
On Tue, 2007-11-06 at 14:32 -0900, Jeff Spaleta wrote:
On 11/6/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
> This will change soon for gdm, I think. The gdm rewrite will make it
> possible to have a keyboard layout selector on the login screen, very
> similar to what you have inside the session. At least that is one of the
> goals.
Would it be possible for gdm to know what each user prefers as a
keyboard layout?
Like if I use the face browser and select a user foo with the mouse.
Can gdm know user foo's default keyboard layout and use it for the
password entry?
You mean the value that you set inside your session ? Unlikely, unless
you want gdm to poke around in the gconf database in your home
directory. I guess it would be possible to make gdm remember the value
you set on the login screen per-user and set it up for you if you use
the face browser. That is not going to help for the user name entry,
though...
6:25 p.m.
On 11/6/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
You mean the value that you set inside your session ? Unlikely,
unless
you want gdm to poke around in the gconf database in your home
directory. I guess it would be possible to make gdm remember the value
you set on the login screen per-user and set it up for you if you use
the face browser. That is not going to help for the user name entry,
though...
right.. but isnt that sort of the point of the face browser..so you
don't have to use the keyboard for username entry?
-jef
11:58 p.m.
On Tue, 2007-11-06 at 15:25 -0900, Jeff Spaleta wrote:
On 11/6/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
> You mean the value that you set inside your session ? Unlikely, unless
> you want gdm to poke around in the gconf database in your home
> directory. I guess it would be possible to make gdm remember the value
> you set on the login screen per-user and set it up for you if you use
> the face browser. That is not going to help for the user name entry,
> though...
right.. but isnt that sort of the point of the face browser..so you
don't have to use the keyboard for username entry?
Sure. I was trying to make the point that you still need to have a
keyboard selector on the login screen, for people who prefer typing
their name.
12:08 a.m.
On Nov 6, 2007 8:58 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
Sure. I was trying to make the point that you still need to have a
keyboard selector on the login screen, for people who prefer typing
their name.
Sure, I didn't mean to imply you could get away with not having the
selector present. I was just thinking that you could link a default
layout per user in the browser as a convienence so my chinese
co-worker doesn't need to re-select every time they go to login.
-jef
9:39 a.m.
Adam Jackson (ajackson(a)redhat.com) said:
This X server requires libpciaccess. Not all of the drivers have
been
ported yet. Not all of them will be ported by Monday, though I'll try
to have the big three of {radeon,intel,nv} and the vesa driver converted
by then. This should cover most people. I hope.
Is there any reason to do the rebase until this is done for
radeon/intel/nv?
Bill
9:21 a.m.
On Tue, 2007-11-06 at 10:39 -0500, Bill Nottingham wrote:
Adam Jackson (ajackson(a)redhat.com) said:
> This X server requires libpciaccess. Not all of the drivers have been
> ported yet. Not all of them will be ported by Monday, though I'll try
> to have the big three of {radeon,intel,nv} and the vesa driver converted
> by then. This should cover most people. I hope.
Is there any reason to do the rebase until this is done for
radeon/intel/nv?
No. I should have phrased this better: the rebase won't happen until
those are done. But I expect that'll be Monday.
- ajax
7:28 p.m.
On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
I plan to rebase the X server to git master a week from today
(Monday,
November 12), which means the changes should hit rawhide on Tuesday.
Okay, so that didn't happen. But things are mostly built now, at least
for the big important core bits. They should be on their way to a
mirror near you tomorrow, assuming the rawhide push goes out.
If you're not using radeon/nv/intel, expect that X will break, and that
you'll need to switch to vesa or fbdev. If you're using an input driver
other than keyboard or mouse, expect those devices to stop working.
I'll be cleaning up the rest of the mess as we go. Please do file bugs
about any weirdness you encounter (outside of the above known caveats).
- ajax
11:04 a.m.
On Nov 13, 2007 5:28 PM, Adam Jackson <ajackson(a)redhat.com> wrote:
On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.
Okay, so that didn't happen. But things are mostly built now, at least
for the big important core bits. They should be on their way to a
mirror near you tomorrow, assuming the rawhide push goes out.
If you're not using radeon/nv/intel, expect that X will break, and that
you'll need to switch to vesa or fbdev. If you're using an input driver
other than keyboard or mouse, expect those devices to stop working.
I'll be cleaning up the rest of the mess as we go. Please do file bugs
about any weirdness you encounter (outside of the above known caveats).
Gave it a try with a laptop with an ATI R300 card. Graphics works just fine.
With the xserver from a few days ago, compiz doesn't want to start on
several machines.
Synaptics didn't load so no mouse. (Ooops, I should have read between the lines)
darrell
5:41 p.m.
On Nov 13, 2007 8:28 PM, Adam Jackson <ajackson(a)redhat.com> wrote:
On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.
Okay, so that didn't happen. But things are mostly built now, at least
for the big important core bits. They should be on their way to a
mirror near you tomorrow, assuming the rawhide push goes out.
If you're not using radeon/nv/intel, expect that X will break, and that
you'll need to switch to vesa or fbdev. If you're using an input driver
other than keyboard or mouse, expect those devices to stop working.
I'll be cleaning up the rest of the mess as we go. Please do file bugs
about any weirdness you encounter (outside of the above known caveats).
I did update my Rahwid system, aftder reboot, no more X.
here is the last from /var/log/Xorg.0.log
ABI class: X.Org XInput driver, version 2.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
965GM, 965GME/GLE, G33, Q35, Q33
(II) Primary Device is: PCI 00@00:02:0
(EE) No devices detected.
Fatal server error:
no screens found
I have xorg-x11-server-common-1.4.99.1-0.10.fc9
/yonas
9:11 a.m.
On Wed, 2007-11-14 at 18:41 -0500, yonas Abraham wrote:
I did update my Rahwid system, aftder reboot, no more X.
here is the last from /var/log/Xorg.0.log
ABI class: X.Org XInput driver, version 2.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
965GM, 965GME/GLE, G33, Q35, Q33
(II) Primary Device is: PCI 00@00:02:0
(EE) No devices detected.
Fatal server error:
no screens found
lspci?
- ajax
9:38 a.m.
On 11/15/07, Adam Jackson <ajackson(a)redhat.com> wrote:
On Wed, 2007-11-14 at 18:41 -0500, yonas Abraham wrote:
> I did update my Rahwid system, aftder reboot, no more X.
>
> here is the last from /var/log/Xorg.0.log
>
> ABI class: X.Org XInput driver, version 2.0
> (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
> i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
> 965GM, 965GME/GLE, G33, Q35, Q33
> (II) Primary Device is: PCI 00@00:02:0
> (EE) No devices detected.
>
> Fatal server error:
> no screens found
lspci?
[yonas@siempc ~]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory
Controller Hub (rev 04)
00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI
Express Root Port (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL
Integrated Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation 82915G Integrated
Graphics Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation
82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC
Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 03)
03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video
and Audio Decoder (rev 05)
03:01.0 Multimedia controller: Pinnacle Systems Inc. AV/DV Studio Capture Card
03:01.1 FireWire (IEEE 1394): Pinnacle Systems Inc. Unknown device 0015
03:08.0 Ethernet controller: Intel Corporation 82562ET/EZ/GT/GZ -
PRO/100 VE (LOM) Ethernet Controller (rev 03)
11:03 a.m.
On Wednesday 14 November 2007 01:28:28 Adam Jackson wrote:
I'll be cleaning up the rest of the mess as we go. Please do
file bugs
about any weirdness you encounter (outside of the above known caveats).
In my case the driver sis was not present, so I have reset to vesa according
to your advice.
Vesa does not work because my monitor warns "Attention, Out of range,
H:89.6KHz V:59.7Hz". To regain the control of the screen I have to kill X.
I have removed the horizontal and vertical ranges from the configuration
file to allow DDC probing and the result is the same.
Attached I send the log and lspci output.
This is the same monitor that I have filled a bugzilla recently because it did
not allowed anymore the 1280*1024 resolution that used to allow until some
weeks ago.
https://bugzilla.redhat.com/show_bug.cgi?id=353641
- ajax
--
José Abílio
2:26 p.m.
On Thu, 2007-11-15 at 17:03 +0000, José Matos wrote:
On Wednesday 14 November 2007 01:28:28 Adam Jackson wrote:
> I'll be cleaning up the rest of the mess as we go. Please do file bugs
> about any weirdness you encounter (outside of the above known caveats).
In my case the driver sis was not present, so I have reset to vesa according
to your advice.
Vesa does not work because my monitor warns "Attention, Out of range,
H:89.6KHz V:59.7Hz". To regain the control of the screen I have to kill X.
I have removed the horizontal and vertical ranges from the configuration
file to allow DDC probing and the result is the same.
Attached I send the log and lspci output.
This is the same monitor that I have filled a bugzilla recently because it did
not allowed anymore the 1280*1024 resolution that used to allow until some
weeks ago.
https://bugzilla.redhat.com/show_bug.cgi?id=353641
Yeah, I remember that one. I think I know what the fix should be for
that situation now, just need to write it.
- ajax
11:24 a.m.
Some doc on how to setup input in the brave new hotplug world for
non-qwerty users would be nice.
I hereby donate my previous working xorg.conf input sections as an
exemple:
Section "InputDevice"
Identifier "nek4k-base"
Driver "evdev"
Option "Protocol" "evdev"
Option "vendor" "1118"
Option "product" "219"
Option "Phys" "*/input0"
Option "XkbModel" "evdev"
Option "XkbLayout" "fr,ru"
Option "XkbVariant" "oss,winkeys"
Option "XkbOptions"
"grp:lwin_toggle,grp_led:scroll,compose:rwin"
Option "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "nek4k-enhanced"
Driver "evdev"
Option "Protocol" "evdev"
Option "vendor" "1118"
Option "product" "219"
Option "Phys" "*/input1"
Option "SendCoreEvents"
EndSection
Section "InputDevice"
Identifier "track-expl"
Driver "evdev"
Option "Protocol" "evdev"
Option "vendor" "1118"
Option "product" "36"
Option "ZAxisMapping" "4 5"
Option "Buttons" "7"
Option "CorePointer"
EndSection
I'm sure it's complex enough that if you explain us how to express this
with the new xorg everyone on the list will manage to adapt his setup.
Regards,
--
Nicolas Mailhot
2:02 p.m.
Le mercredi 14 novembre 2007 à 13:08 -0500, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> Some doc on how to setup input in the brave new hotplug world for
> non-qwerty users would be nice.
>
> I hereby donate my previous working xorg.conf input sections as an
> exemple:
evdev isn't there yet.
The problem is not evdev, it was working in F8, the problem is how the
new rawhide xorg moves all the input bits out of xorg.conf and there's
no documentation I know of on the new input hotplug configuration.
(also the new stuff uses evdev by default but let me repeat that's not
the problem — this part works)
--
Nicolas Mailhot
5:28 p.m.
On Wed, 2007-11-14 at 21:02 +0100, Nicolas Mailhot wrote:
Le mercredi 14 novembre 2007 à 13:08 -0500, Bill Nottingham a écrit
:
> Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> > Some doc on how to setup input in the brave new hotplug world for
> > non-qwerty users would be nice.
> >
> > I hereby donate my previous working xorg.conf input sections as an
> > exemple:
>
> evdev isn't there yet.
The problem is not evdev, it was working in F8, the problem is how the
new rawhide xorg moves all the input bits out of xorg.conf and there's
no documentation I know of on the new input hotplug configuration.
Why yes, that is a problem.
It's also not something I've looked into at all yet. I would be
thrilled to have contributions in this area, if you're looking for a
project.
- ajax
4:07 p.m.
Adam Jackson wrote:
It's also not something I've looked into at all yet. I would
be
thrilled to have contributions in this area, if you're looking for a
project.
What's missing?
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
8:24 a.m.
Adam Jackson wrote:
I plan to rebase the X server to git master a week from today
(Monday,
November 12), which means the changes should hit rawhide on Tuesday.
I'm interested in getting a few drivers going that haven't made it to
rawhide yet. In particular, 'via'
and 'mga'. What's the best process for helping out with this? Is is
straight forward to just grab
the latest driver from GIT and build a new/improved RPM?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
9:47 a.m.
On Mon, 2007-11-19 at 07:24 -0700, Gary Thomas wrote:
Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.
>
I'm interested in getting a few drivers going that haven't made it to
rawhide yet. In particular, 'via'
and 'mga'. What's the best process for helping out with this? Is is
straight forward to just grab
the latest driver from GIT and build a new/improved RPM?
Grab the newest driver from git, update the buildreqs in the specfile to
be xorg-x11-server-devel >= 1.4.99.1, and try to build it. If it works,
awesome. If not, the driver probably needs to be ported to
libpciaccess.
There's a rough howto for porting on the Xorg wiki:
http://xorg.freedesktop.org/wiki/PciReworkHowto
It's mostly mechanical, but there are some bits that may require actual
understanding of PCI. If you port a driver and get it working, either
send me the patch or post it to xorg(a)lists.freedesktop.org and we'll get
it merged.
- ajax
11:38 p.m.
On Mon, 19 Nov 2007 10:47:29 -0500, Adam Jackson <ajackson(a)redhat.com> wrote:
http://xorg.freedesktop.org/wiki/PciReworkHowto
It's mostly mechanical, but there are some bits that may require actual
understanding of PCI. If you port a driver and get it working, either
send me the patch or post it to xorg(a)lists.freedesktop.org and we'll get
it merged.
I am having trouble with sis. The PCI stuff is easy, I've done it.
However, the driver has about half a dozen places with something like:
src/sis_dri.c:#if XORG_VERSION_CURRENT < XORG_VERSION_NUMERIC(6,7,99,1,0)
But this is nonsensual, because:
/usr/include/xorg/xorg-server.h:#define XORG_VERSION_CURRENT (((1) * 10000000) +
((4) * 100000) + ((0) * 1000) + 1)
It looks like the code expected major 7, but we define 1 in xorg-server.h.
How did that thing even build before the PCI rework? Even if it built,
the build enabled all the wrong options. What should be done?
xorg-x11-server-devel-1.4.99.1-0.10.fc9
libdrm-devel-2.4.0-0.1.fc9
-- Pete
1:17 p.m.
Gary Thomas wrote:
Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.
>
I'm interested in getting a few drivers going that haven't made it to
rawhide yet. In particular, 'via'
and 'mga'. What's the best process for helping out with this? Is is
straight forward to just grab
the latest driver from GIT and build a new/improved RPM?
xorg-x11-drv-via is dead, it's been replaced by xorg-x11-drv-openchrome
which has just been ported to libpciaccess. Please grab it from rawhide
and report bugs either to openchrome.org bug tracker or in RH bugzilla.
Regards,
Xavier
5995
days inactive
6028
days old
35 comments
16 participants
participants (16)
-
Adam Jackson -
Bernie Innocenti -
Bill Nottingham -
darrell pfeifer -
Gary Thomas -
Jef Spaleta -
Jesse Keating -
José Abílio Matos -
Matthias Clasen -
Nicolas Mailhot -
Pete Zaitcev -
Peter Robinson -
Richi Plana -
Xavier Bachelot -
Yaakov Nemoy -
Yonas Abraham