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
Keysyms: HomePage vs WWW
Hi folks Today I looked at the usage of I32 in symbols/inet and found interesting thing. There are 31 cases where it is used as XF86WWW and 17 cases where it is used as XF86HomePage. Could anyone explain the substantial difference between these 2 keysyms (in the context of desktop)? May be, we could just declare WWW as deprecated and switch entirely to HomePage? Or - the other way around? There are more exotic cases for that key, like Search, Finance etc - I guess I'll just leave them as they are. For a moment, at least;) Maniac of unification AKA Sergey ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Broken X11 After Mandriva Upgrade
Thanks again for the reply. Please see embedded comments. - gmane wrote: Actually this is wrong. We didn't split out the intel drivers back out at that point it seems. I guess it was only did that later. I'm trying to remember if there is was a problem with 2008.0 or not. It was caused by switching to the 2.x series IIRC and there were a few regressions with that. If anyone knows when the below problem was fixed (e.g. in what version) that would be useful as I can then do a backport for you on 2008.0. Just for the record, neither vesa nor vga work either. Failing a known fix for the problem above, you can also try installing the -i180 rpm from 2007.1 I think that should still work and not cause this problem due ot the fact it was still on the 1.7.x series IIRC. I found this package on the CD from 2007.0: x11-driver-video-i810-1.6.5-2mdv2007.0.i586.rpm Hopefully that is what you meant. You may have to download the RPM mandually and install with --oldpackage argument to rpm. I have never tried to back level a version until now. When I try to install version 1.6.5-2 (using 'urpmi'), even using --oldpackage, it fails. I get 3 errors refering to conflicts with a file in package ... where the referenced package is the newer version of the driver, 2.1.1-4 and the files are /usr/lib/I810XvMC.so.1.0.0, /usr/lib/I810XvMC.la and /usr/lib/xorg/modules/drivers/i810_drv.so. Do I need to uninstall the newer package first or did I do something else wrong? _ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
trouble setting up dual layout keyboard
Hello,
I'm using X.Org 1.5.2 (the one shipped with ubuntu intrepid ibex) and
I would like to setup my keyboard in the following way:
- use two layouts: US and french
- switch between the layouts by pressing both alt keys together
- use the caps lock key as compose
I tried this command:
$ setxkbmap -model evdev -layout fr,us -option grp:alts_toggle
-option compose:caps
Which results in
$ setxkbmap -print
xkb_keymap {
xkb_keycodes { include evdev+aliases(azerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include
pc+fr+us:2+inet(evdev)+level3(ralt_switch_for_alts_toggle):1+level3(ralt_switch_for_alts_toggle):2+group(alts_toggle)+compose(caps)
};
xkb_geometry { include pc(pc104) };
However, it does not work perfectly:
* Pressing both alt keys switch from US to french but does not switch
back to french
* In the US layout caps lock key behaves as caps lock (bad). In the
french layout, the caps lock key behaves simultaneously as compose and
caps lock
I'm quite lost, and the doc I found [1] was not much helpful. I cannot
believe I'm the only one with such settings. Any idea why it does not
work ?
[1] http://www.x.org/wiki/XKB
--
Thank you in advance,
Sébastien Barthélemy
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken X11 After Mandriva Upgrade
- gw1500se wrote: If anyone knows when the below problem was fixed (e.g. in what version) that would be useful as I can then do a backport for you on 2008.0. Just for the record, neither vesa nor vga work either. Hmm, sounds like something more fundamental is wrong then. I'd imagine your upgrades have perhaps not gone overly smoothly :s Perhaps you can supply your full xorg.log (a link to a pastebin would be nicer than attaching). Failing a known fix for the problem above, you can also try installing the -i180 rpm from 2007.1 I think that should still work and not cause this problem due ot the fact it was still on the 1.7.x series IIRC. I found this package on the CD from 2007.0: x11-driver-video-i810-1.6.5-2mdv2007.0.i586.rpm As I said above, I'd go for the 2007.1 version: x11-driver-video-i810-1.7.4-22mdv2007.1.i586.rpm You can donwload this from here: ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/official/2007.1/i586/media/main/release/x11-driver-video-i810-1.7.4-22mdv2007.1.i586.rpm You may have to download the RPM mandually and install with --oldpackage argument to rpm. I have never tried to back level a version until now. When I try to install version 1.6.5-2 (using 'urpmi'), even using --oldpackage, it fails. I get 3 errors refering to conflicts with a file in package ... where the referenced package is the newer version of the driver, 2.1.1-4 and the files are /usr/lib/I810XvMC.so.1.0.0, /usr/lib/I810XvMC.la and /usr/lib/xorg/modules/drivers/i810_drv.so. Do I need to uninstall the newer package first or did I do something else wrong? You may have to remove the currently installed package first yes. You can do: rpm -e --nodeps x11-driver-video-intel rpm -Uvh x11-driver-video-i810-1.7.4-22mdv2007.1.i586.rpm I wouldn't normally recommend doing this kind of thing but if things really are not working for you then this could help. 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: [PATCH 12/12] xkb: don't attempt to filter events for devices without key classes.
On Fri, Nov 28, 2008 at 10:20:55AM -0800, Keith Packard wrote: On Fri, 2008-11-28 at 17:03 +1000, Peter Hutterer wrote: (a huge pile of patches) These all look good to me; can you push them to a branch off of 1.6 so I can merge them in? I think I added that url in my first email, but anyway: git://people.freedesktop.org/~whot/xserver server-1.6-branch Just freshly rebased onto commit db115e78705e59a376c6c425e7cb97cfb14ff2ac Author: George Staplin [EMAIL PROTECTED] Date: Fri Nov 28 13:57:45 2008 -0700 XQuartz: GL: Make various changes to makeFormat, so that it works better. Oh, the one question I had was about XGE -- I don't see any reason to remove this extension as it seems stable and will make back-porting XI2 to 1.6 servers a bit easier. Leave it in? Take it out? I'd say leave it in, even though we don't have any consumers of XGE right now. There's a bit of code that I'd consider iffy but that's all in-server and can be changed w/o breaking anything. I'll go through the externally visible stuff this week and get a proper protocol spec out so we can finalise anything missing. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keysyms: HomePage vs WWW
James, Thanks for the insightful information - really interesting. Unfortunately, as we all know, XKB is not that smart - it cannot distinguish application launch context from application control context. So a keysym has to be mapped to the keycode unconditionally. My question was: what would be the best XKB mapping for the keycode I32 (the keycode itself does not matter, it is just happen to be used frequently for THAT key). As an option, we could declare 2 shift levels - one for App Launch context (WWW), second for App Control context (HomePage). I just want some consistent approach, you know... Sergey ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev: keyboard or mouse?
On Fri, Nov 28, 2008 at 05:58:22AM -0800, Sebastian Glita wrote: The mice and keyboards in xf86-input-evdev/src/evdev.c:EvdevProbe handle a multiple-capability device wrong for my use. I have a wireless USB receiver so I use both a mouse and a keyboard with the same token. In `hal-device`, the device for the mouse also has input.keys matching info.capabilities. I tried in /etc/hal/fdi/10-x11-input.fdi to remove from info.capabilities the info.keys from this strlist. It works. The device probing is independent of HAL, so removing this key won't affect evdev at all. The problem is that in `gnome-device-setup' when I drag the name from the Virtual Core Pointer it goes only to a keyboard item, and not to the pointer one (its use matches IsXExtensionKeyboard instead of IsXExtensionPointer). Unless someone has actually taken the code and advanced it, I wouldn't trust on gnome-device-setup 100%. Try xinput --reattach mouse name Virtual core pointer and see if that works. This small permutation in evdev.c works for me (it disables `has_keys' in favor of XI_MOUSE to XI_KEYBOARD): please always submit code changes as diffs, otherwise it's too hard to figure out what the actual change was. if (has_axes num_buttons) has_keys = FALSE; No. Doing so means you essentially disable all keys on the device. I've seen keyboards that advertise buttons and axes (scrollwheel) so you'd be disabling all these keyboards. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] If AEI is on, disable 'vmmouse' in addition to 'kbd' and 'mouse'.
On Fri, Nov 28, 2008 at 02:55:55PM +0200, Timo Aaltonen wrote:
---
hw/xfree86/common/xf86Config.c |5 +++--
hw/xfree86/doc/man/xorg.conf.man.pre |2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index a6290a7..b05b283 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -2460,13 +2460,14 @@ checkInput(serverLayoutPtr layout, Bool
implicit_layout) {
while(*dev)
{
if (strcmp((*dev)-driver, kbd) == 0 ||
-strcmp((*dev)-driver, mouse) == 0)
+strcmp((*dev)-driver, mouse) == 0 ||
+strcmp((*dev)-driver, vmmouse) == 0)
{
IDevPtr *current;
if (!warned)
{
xf86Msg(X_WARNING, AllowEmptyInput is on, devices using
-drivers 'kbd' or 'mouse' will be disabled.\n);
+drivers 'kbd', 'mouse' or 'vmmouse' will be
disabled.\n);
warned = TRUE;
}
diff --git a/hw/xfree86/doc/man/xorg.conf.man.pre
b/hw/xfree86/doc/man/xorg.conf.man.pre
index 3baa7fb..e68c156 100644
--- a/hw/xfree86/doc/man/xorg.conf.man.pre
+++ b/hw/xfree86/doc/man/xorg.conf.man.pre
@@ -696,7 +696,7 @@ the X server to load. Disabled by default.
If enabled, don't add the standard keyboard and mouse drivers, if there are
no
input devices in the config file. Enabled by default if AutoAddDevices and
AutoEnableDevices is enabled, otherwise disabled.
-If AllowEmptyInput is on, devices using the kbd or mouse driver are ignored.
+If AllowEmptyInput is on, devices using the kbd, mouse or vmmouse driver are
ignored.
.TP 7
.BI Option \*qAutoAddDevices\*q \*q boolean \*q
If this option is disabled, then no devices will be added from HAL events.
--
1.6.0.4
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
Cheers,
Peter
___
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: Sergey Unfortunately, as we all know, XKB ... cannot distinguish Sergey application launch context from application control context. Apologies for ambiguity. These are two completely different keys at the USB level; it is really the keyboard manufacturer who decides which the key is. If keyboards which use I32 with the kbd driver generate I158 in evdev I'd make I32 be WWW and if they generate I180 when using evdev then HomePage. (I presume the mapping between keycodes/xfree86's I32 when using kbd and keycodes/evdev's I158 or I180 when using evdev is consistant across all keyboards.) Sergey I just want some consistent approach, you know... I agree with that! -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
Twas brillig at 10:28:24 01.12.2008 UTC+10 when [EMAIL PROTECTED] did gyre and gimble: PH Most other settings in the more popular input drivers are now PH configurable at runtime too (where now == server 1.6), so you PH basically just have to convince your DE to provide pretty PH interfaces for them. There is whole world without DEs. -- pgpbxzMEbCpSF.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xfree86: don't FatalError on too many input devices.
Just ignore devices after MAXDEVICES has been reached, but warn the user that
the devices are ignored.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
hw/xfree86/common/xf86InPriv.h |2 +-
hw/xfree86/common/xf86Init.c |4 +++-
hw/xfree86/common/xf86Xinput.c | 29 -
hw/xfree86/common/xf86Xinput.h |2 +-
4 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/hw/xfree86/common/xf86InPriv.h b/hw/xfree86/common/xf86InPriv.h
index 62e4820..3838d69 100644
--- a/hw/xfree86/common/xf86InPriv.h
+++ b/hw/xfree86/common/xf86InPriv.h
@@ -38,7 +38,7 @@ extern InputDriverPtr *xf86InputDriverList;
extern int xf86NumInputDrivers;
/* xf86Xinput.c */
-void xf86ActivateDevice(InputInfoPtr pInfo);
+int xf86ActivateDevice(InputInfoPtr pInfo);
/* xf86Helper.c */
InputDriverPtr xf86LookupInputDriver(const char *name);
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index a2cccd5..d0408a9 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -1321,7 +1321,9 @@ InitInput(argc, argv)
strcpy((*pDev)-driver, kbd);
}
-xf86NewInputDevice(*pDev, dev, TRUE);
+/* If one fails, the others will too */
+if (xf86NewInputDevice(*pDev, dev, TRUE) == BadAlloc)
+break;
}
mieqInit();
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 376af77..89a27c7 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -287,12 +287,13 @@ xf86ProcessCommonOptions(LocalDevicePtr local,
/***
*
* xf86ActivateDevice --
- *
+ *
* Initialize an input device.
*
+ * Returns TRUE on success, or FALSE otherwise.
***
*/
-_X_EXPORT void
+_X_EXPORT int
xf86ActivateDevice(LocalDevicePtr local)
{
DeviceIntPtr dev;
@@ -301,8 +302,13 @@ xf86ActivateDevice(LocalDevicePtr local)
dev = AddInputDevice(serverClient, local-device_control, TRUE);
if (dev == NULL)
-FatalError(Too many input devices);
-
+{
+xf86Msg(X_ERROR, Too many input devices. Ignoring %s\n,
+local-name);
+local-dev = NULL;
+return FALSE;
+}
+
local-atom = MakeAtom(local-type_name,
strlen(local-type_name),
TRUE);
@@ -334,6 +340,8 @@ xf86ActivateDevice(LocalDevicePtr local)
xf86Msg(X_INFO, XINPUT: Adding extended input device \%s\
(type: %s)\n,
local-name, local-type_name);
}
+
+return TRUE;
}
@@ -470,6 +478,13 @@ AddOtherInputDevices()
/**
* Create a new input device, activate and enable it.
*
+ * Possible return codes:
+ *BadName .. a bad driver name was supplied.
+ *BadImplementation ... The driver does not have a PreInit function. This
+ * is a driver bug.
+ *BadMatch .. device initialization failed.
+ *BadAlloc .. too many input devices
+ *
* @param idev The device, already set up with identifier, driver, and the
* options.
* @param pdev Pointer to the new device, if Success was reported.
@@ -519,7 +534,11 @@ xf86NewInputDevice(IDevPtr idev, DeviceIntPtr *pdev, BOOL
enable)
goto unwind;
}
-xf86ActivateDevice(pInfo);
+if (!xf86ActivateDevice(pInfo))
+{
+rval = BadAlloc;
+goto unwind;
+}
dev = pInfo-dev;
ActivateDevice(dev);
diff --git a/hw/xfree86/common/xf86Xinput.h b/hw/xfree86/common/xf86Xinput.h
index aa1f162..3db658b 100644
--- a/hw/xfree86/common/xf86Xinput.h
+++ b/hw/xfree86/common/xf86Xinput.h
@@ -166,7 +166,7 @@ void xf86PostKeyEvent(DeviceIntPtr device, unsigned int
key_code, int is_down,
...);
void xf86PostKeyboardEvent(DeviceIntPtr device, unsigned int key_code,
int is_down);
-void xf86ActivateDevice(LocalDevicePtr local);
+int xf86ActivateDevice(LocalDevicePtr local);
LocalDevicePtr xf86FirstLocalDevice(void);
int xf86ScaleAxis(int Cx, int Sxhigh, int Sxlow, int Rxhigh, int Rxlow);
void xf86XInputSetScreen(LocalDevicePtr local, int screen_number, int x, int
y);
--
1.6.0.3
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Peter Hutterer wrote: On Sun, Nov 30, 2008 at 09:17:47PM +0500, Alexander E. Patrakov wrote: However, xorg gets things like keyboard layouts from HAL. This is also policy, and also important to get i18n right. But, for some reason, this is allowed to exist in HAL, and default mount options aren't. Could you, xorg/HAL developers, at least be consistent, and either undeprecate volume.policy.mount_option.*, or invent a different place (i.e., something else than fdi files) to keep the default keyboard layout and deprecate the corresponding HAL keys? You can change the keyboard layout at runtime, and the majority of users do exactly that by setting the layout in their desktop environment. So having that in HAL is not necessary in most cases. Obvious problem: it is too late to set the keyboard layout in the desktop environment. The user has to type the login and the password into the display manager, and the keyboard layout has to be correct at this stage, too. Most other settings in the more popular input drivers are now configurable at runtime too (where now == server 1.6), so you basically just have to convince your DE to provide pretty interfaces for them. May I then convince XDM maintainers to provide such interface or, if this is impossible, to drop this broken software from Xorg? Well, in fact, there is such interface (the Xsetup_0 file), it just lacks the comment that such commands should be placed there. If this works without races (i.e., if the setxkbmap command there will modify the layout for both currently connected keyboards and the default for future devices), I will consider the issue closed as long as this command (commented-out by default) is added there in GIT. -- Alexander E. Patrakov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Peter Hutterer wrote: adding the list back On Mon, Dec 01, 2008 at 09:55:03AM +0500, Alexander E. Patrakov wrote: Obvious problem: it is too late to set the keyboard layout in the desktop environment. The user has to type the login and the password into the display manager, and the keyboard layout has to be correct at this stage, too. obvious solution: let the display manager set the keyboard layout? although others may disagree, for me the DM counts as part of the DE as well. Then, what DE does XDM count as a part of? Well, in fact, there is such interface (the Xsetup_0 file), it just lacks the comment that such commands should be placed there. If this works without races (i.e., if the setxkbmap command there will modify the layout for both currently connected keyboards and the default for future devices), I will consider the issue closed as long as this command (commented-out by default) is added there in GIT. isn't X supposed to be mechanism, not policy? we provide the hooks, let someone else decide on how to use them. X provides the hooks for setting the keymap, you'll need to trigger them somehow. OK. However, the policy should have some centralized implementation usable by all DEs, as I don't want to convince each and every DE to invent their own wheel. Also, currently, for unconfigured Xorg, such newly-added keyboard gets the us layout. This is also a hard-coded policy, should we remove it? 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. setxkbmap won't be able to set the layouts for future devices. Then something is bad. Suppose that, due to EMI, the kernel decided to disconnect and reconnect the USB keyboard after setxkbmap has set the layout for it. Who will reset the layout for it? XDM currently can't run programs in response to such events. Should I report this as a bug? -- Alexander E. Patrakov ___ 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 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. 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
On Mon, Dec 01, 2008 at 10:47:06AM +0500, Alexander E. Patrakov wrote: Peter Hutterer wrote: adding the list back On Mon, Dec 01, 2008 at 09:55:03AM +0500, Alexander E. Patrakov wrote: Obvious problem: it is too late to set the keyboard layout in the desktop environment. The user has to type the login and the password into the display manager, and the keyboard layout has to be correct at this stage, too. obvious solution: let the display manager set the keyboard layout? although others may disagree, for me the DM counts as part of the DE as well. Then, what DE does XDM count as a part of? I was referring to DE as a concept, not as a specific implementation. It counts as part of whatever you're running afterwards, may be gnome, kde, xfce or my-happy-bunch-of-shellscripts. Also, currently, for unconfigured Xorg, such newly-added keyboard gets the us layout. This is also a hard-coded policy, should we remove it? 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. Well, if you don't map your keycodes to something, you won't be able to type anything. us is traditionally the default and I'll let others have a flamewar about that. setxkbmap won't be able to set the layouts for future devices. Then something is bad. Suppose that, due to EMI, the kernel decided to disconnect and reconnect the USB keyboard after setxkbmap has set the layout for it. Who will reset the layout for it? XDM currently can't run programs in response to such events. Should I report this as a bug? Then you need a client in the background notifying you that a new device was added, either prompting you to update the keymap, or runs it directly. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XGE protocol spec
Below is the protocol spec for the X Generic Event Extension (XGE). It'll be shipped with 1.6 even though there won't be any consumers for it yet. (This is the current proto/xextproto/geproto.txt file as valid in my tree. Will be pushed pending no objections.) Cheers, Peter X Generic Event Extension Peter Hutterer [EMAIL PROTECTED] 1. Introduction 2. Extension Initialization 3. Extension Events 4. Notes _ 1. Introduction X was designed to provide 64 event opcodes for all extensions. These events are limited to 32 bytes. The Generic Event Extension is a template for extensions to re-use a single event opcode. GE only provide headers and the most basic functionality, leaving the extensions to interpret the events in their specific context. GenericEvents may be longer than 32 bytes. If so, the number of 4 byte units following the initial 32 bytes must be specified in the length field of the event. _ 2. Extension Initialization The name of this extension is Generic Event Extension ┌─── GEQueryVersion client-major-version: CARD16 client-minor-version: CARD16 ▶ major-version: CARD16 minor-version: CARD16 └─── The client sends the highest supported version to the server and the server sends the highest version it supports, but no higher than the requested version. Major versions changes can introduce incompatibilities in existing functionality, minor version changes introduce only backward compatible changes. It is the clients responsibility to ensure that the server supports a version which is compatible with its expectations. As of version 1.0, no other requests are provided by this extension. _ 3. Extension Events GE defines a single event, to be used by all extensions. The event's structure is similar to a request. ┌─── 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 field 'extension' is to be set to the major opcode of the extension. The 'evtype' field is the actual opcode of the event. The length field specifies the number of 4-byte blocks after the initial 32 bytes. _ 4. Notes Although the wire event is of arbitrary length, the actual size of an XEvent is restricted to sizeof(XEvent) [96 bytes, see Xlib.h]. If an extension converts a wire event to an XEvent 96 bytes, it will overwrite the space acllocated for the event. See struct _XSQEvent in Xlibint.h for details. Extensions need to malloc additional data and fill the XEvent structure with pointers to the malloc'd data. The client then needs to free the data, only the XEvent structure will be released by Xlib. The server must not send GenericEvents longer than 32 bytes until it has verified that the client is able to interpret these events. If a long event is sent to a client unable to process GenericEvents, future interpretation of replies and events by this client will fail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Peter Hutterer wrote: I was referring to DE as a concept, not as a specific implementation. It counts as part of whatever you're running afterwards, may be gnome, kde, xfce or my-happy-bunch-of-shellscripts. OK. Anyway, my point about XDM as the example implementation not following the modern guidelines was moot, because, as Daniel Stone said, XDM is no longer in the standard Xorg distribution. Also, currently, for unconfigured Xorg, such newly-added keyboard gets the us layout. This is also a hard-coded policy, should we remove it? 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. Well, if you don't map your keycodes to something, you won't be able to type anything. Yes, that's the point. This will force the maintainers of Linux distributions with US origin (to Daniel Stone: they are obviously not the same people as the input maintainers in Xorg) to do the right thing for everyone, instead of just not noticing the problem because non-US users think that the keyboard is obviously broken beyond repair (and thus not reporting the obvious bug). us is traditionally the default and I'll let others have a flamewar about that. 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.e.: Windows has a useful notion of the global default keyboard layout, and stores it in the registry. Xorg gets this from xorg.conf (that is going to disappear from modern setups), HAL (not a good place for policy), runtime configuration (excellent idea, but with no existing clients usable from, say, Slim), falling back to us (and often distro maintainers don't notice this). setxkbmap won't be able to set the layouts for future devices. Then something is bad. Suppose that, due to EMI, the kernel decided to disconnect and reconnect the USB keyboard after setxkbmap has set the layout for it. Who will reset the layout for it? XDM currently can't run programs in response to such events. Should I report this as a bug? Then you need a client in the background notifying you that a new device was added, either prompting you to update the keymap, or runs it directly. Then it may be a good idea to write such client (even without the pop-up, a static default stored in the configuration file will also work) and add it to xorg-apps as an example implementation of such service. -- Alexander E. Patrakov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
I just want to voice my dislike of the HAL input layer stuff, but just that it's the default. Right now that doesn't make any sense. I try to keep uptodate with current GIT to make sure sparc doesn't break. 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 started adding --disable-builtin-fonts to xserver's configure run to work around this. It's fine to add new facilities and encourage major distributions to move to those facilities. But you do it by making the new facility not the default, but something specified explicitly by the distribution builders because only they know that they have a HAL available which will make input device hotplug work properly. My system does not, so Xorg broke with that behavioral change for me. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Using XTestFakeDeviceMotionEvent().
Hi,
The following program (requires XInput2) warps my pointer to (0,0)
instead of the requested (600,400). I'd be interested to know whether
this happens for other people, and if there's something obviously wong
with my code. Thanks!
// gcc -o xtest xtest.c -Wall -I/usr/include/X11 -lX11 -lXtst -lXext -lXi
#include stdio.h
#include X11/Xlib.h
#include X11/extensions/XTest.h
#include X11/extensions/XInput.h
#define FALSE 0
int main() {
Display *xdisplay;
XExtensionVersion *version;
XDeviceInfo *devInfo;
XDevice *xdevice;
int count, i, devPointer;
int axes[] = {600,400};
xdisplay = XOpenDisplay(0);
version = XQueryInputVersion(xdisplay, 2, 0);
if (!(devInfo = XListInputDevices(xdisplay, count)) || !count)
printf(Cannot list devices\n);
for (i = 0; i count; i++) {
if (devInfo[i].use == IsXPointer)
devPointer = i;
}
xdevice = XOpenDevice(xdisplay, devInfo[devPointer].id);
XTestFakeDeviceMotionEvent(xdisplay, xdevice, FALSE, 0, axes, 2, 0);
XFlush(xdisplay);
return 0;
}
--
Chris Ball [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGE protocol spec
On Mon, Dec 01, 2008 at 04:15:47PM +1000, Peter Hutterer wrote: Below is the protocol spec for the X Generic Event Extension (XGE). It'll be shipped with 1.6 even though there won't be any consumers for it yet. (This is the current proto/xextproto/geproto.txt file as valid in my tree. Will be pushed pending no objections.) Signed-off-by: Daniel Stone [EMAIL PROTECTED] Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
