Re: Switch TV output on Intel 945GM to PAL
Konrad Bucheli wrote: > The only problem left is that the TV output flickers once every ten > seconds. Any idea? Wild guess: try adding drm_kms_helper.poll=0 to the kernel command line. -- Alexander E. Patrakov ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
xrandr scaling bug
Hello, I tried playing with xrandr transforms on my 1280x1024 screen. Intention: simulate a lower-resolution screen, add black bars, keep aspect ratio. Result: first it worked, then gave X errors. Also with the non-identity transform, in GTK menus, when selecting a menu item, it is not fully painted in blue initially (looks like a tiling artifact), this corrects itself in half a second or so. I am using Gentoo ~amd64, xorg-server-1.8.0, xf86-video-intel-2.11.0, mesa-7.8.1, linux-2.6.33-gentoo-r2 (contains upstream 2.6.33.3). Here is what I did: a...@home ~ $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) DVI1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48072.8 75.0 66.7 60.0 720x40070.1 a...@home ~ $ xrandr --fb 1024x768 --output DVI1 --transform 1,0,128,0,1,128,0,0,1 xrandr: specified screen 1024x768 not large enough for output DVI1 (1280x1024+128+128) a...@home ~ $ xrandr --fb 1024x768 --output DVI1 --transform 1,0,-128,0,1,-128,0,0,1 xrandr: specified screen 1024x768 not large enough for output DVI1 (1280x1024+-128+-128) a...@home ~ $ xrandr --fb 1280x960 --output DVI1 --transform 1,0,0,0,1,-32,0,0,1 xrandr: specified screen 1280x960 not large enough for output DVI1 (1280x1024+0+-32) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 24 Current serial number in output stream: 26 a...@home ~ $ xrandr --fb 1280x960 --output DVI1 --transform 1,0,0,0,1,-32,0,0,1 xrandr: specified screen 1280x960 not large enough for output DVI1 (1280x1024+0+-32) a...@home ~ $ xrandr --auto X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 24 Current serial number in output stream: 26 a...@home ~ $ xrandr --auto X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 24 Current serial number in output stream: 26 a...@home ~ $ xrandr --output DVI1 --auto X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 24 Current serial number in output stream: 25 -- Alexander E. Patrakov ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GSoC: KMSifying cirrus?
24.03.2010 09:02, Daniel Gnoutcheff wrote: Hello all! I'm planing to apply for GSoC, and Xorg is one of the projects I'm considering. I see that "KMS a non-KMSed driver" is on the ideas list. One of the ideas I'm considering is the KMSification of the cirrus driver (at least the alpine half of it). Would there be any interest in such a project? Cirrus cards are kind of obsolete, but I suppose *would* be nice to have one more KMS driver, perhaps a relatively simple one that could be an easy-to-follow model for other KMSification efforts. I've got a real CL-GD-5446 to do some testing with, and I've spent a bit of time tracking/testing/exploring the git repos for the kernel and for various xorg projects, so I do have a tiny head start there. This will certainly be useful for people who run QEMU or KVM. -- Alexander E. Patrakov ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libpciaccess x86 backend
[If this review is stupid, disregard - I know nothing about PCI internals]
17.01.2010 19:37, Samuel Thibault wrote:
> +sav = inl(0xCF8);
> +outl(0x8000 | (bus<< 16) | (dev<< 11) | (func<< 8) | (reg& ~3),
> 0xCF8);
> +/* NOTE: x86 is already LE */
> +switch (size) {
...
> + default:
> + ret = EIO;
> + break;
> +}
> +outl(sav, 0xCF8);
Here a read or write request that can be rejected right away (wrong
size) still leads to I/O port access. Is it OK?
> + printf("unknown header type %02x\n", header_type);
printf to stdout in a library? Shouldn't that better go to stderr? (btw,
there is another case in src/common_capability.c)
> +/** Returns the size of a region based on the all-ones test value */
> +static int
> +get_test_val_size( uint32_t testval )
> +{
> +int size = 1;
I understand that nobody is going to pass 0x8000 here as testval,
but, should this and the return value be unsigned nevertheless?
> +static int
> +pci_device_x86_read(struct pci_device *dev, void *data,
> +pciaddr_t offset, pciaddr_t size, pciaddr_t *bytes_read)
> +{
> +struct pci_system_x86 *pci_sys_x86 = (struct pci_system_x86 *) pci_sys;
> +int err;
> +
> +*bytes_read = 0;
> +while (size> 0) {
> + int toread = 4;
> + if (toread> size)
> + toread = size;
> + if (toread> 4 - (offset& 0x3))
> + toread = 4 - (offset& 0x3);
Can't it happen that toread == 3 here? Or is this an invalid request?
> +_pci_hidden int
> +pci_system_x86_create(void)
> +{
> +struct pci_device_private *device;
> +int ret, bus, dev, ndevs, func, nfuncs;
> +struct pci_system_x86 *pci_sys_x86;
> +uint32_t reg;
> +
> +ret = x86_enable_io();
> +if (ret)
> + return ret;
> +
> +pci_sys_x86 = calloc(1, sizeof(struct pci_system_x86));
> +if (pci_sys_x86 == NULL) {
> + x86_disable_io();
> + return ENOMEM;
> +}
> +pci_sys =&pci_sys_x86->system;
> +
> +ret = pci_probe(pci_sys_x86);
> +if (ret)
> + return ret;
and stay with io enabled and pci_sys_x86 being non-freed?
> +pci_sys->devices = calloc(ndevs, sizeof(struct pci_device_private));
> +if (pci_sys->devices == NULL) {
> + x86_disable_io();
> + free(pci_sys);
Is this supposed to be free(pci_sys_x86)?
--
Alexander E. Patrakov
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xserver 1.6] RANDR primary output proposal
Keith Packard wrote: > I suspect drivers will want to set the default primary output to > something other than None -- on a laptop, one can imagine always making > the LVDS 'primary'... ...unless this is a "work laptop" that generally sits in its dock with a big monitor attached and external keyboard & mouse connected (as it is the case with my laptop). I use the big monitor for general work and the internal LCD for stuff like KDE's yellow sticky notes, PSI roster and GIMP tool windows. -- Alexander E. Patrakov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
2008/12/1 Corbin Simpson <[EMAIL PROTECTED]>: > Would a udev analogy be appropriate? I think, yes. > udev is a userspace program that > manages a very low-level policy for the kernel. It's responsible for setting > sensible defaults, but can be fully customized in order to fit the needs of > anybody who wants custom layouts. No, the default without any rules is root:root, 0660 for every device. > Why userspace? Because policy shouldn't live in the kernel. Agreed. However, why are the major and minor number in sysfs, instead of some equivalent of devfs? Because they are insufficient to create the device correctly from the first try without the policy. I.e., udev creates a device immediately with the correct permissions, instead of chmoding a kernel-created device (leading to -EPERM race). So the analogy goes this way: Kernel creates a directory in /sys, but no usable device node => Xorg registers an input device, but doesn't make it immediately available (e.g., it starts disabled, if there is such notion in Xorg). Udev takes device major & minor numbers from sysfs and permissions from rules, and then creates the device node => daemon gets the device characteristics (e.g., the fact that it has keys) from Xorg, applies some configuration stored in its database, modifies the device settings and then enables the device, so that in no moment it is enabled, but configured incorrectly. > Why usable defaults? Because customization shouldn't be mandatory. Here we disagree. Debian specifically has acknowledged the need for mandatory customization in some cases. Please see debconf(7) about configuration question priorities: lowVery trivial questions that have defaults that will work in the vast majority of cases. medium Normal questions that have reasonable defaults. high Questions that don't have a reasonable default. critical Questions that you really, really need to see (or else). In their installer, the question about the keyboard layout has the medium priority, but only because the question about the installation language (which is of the critical priority) provides the sensible default. > Why use dbus to talk to the rest of userspace? Because, like it or not, dbus > is probably the best way to do so. Agreed. > Now, the big difference between HAL and udev is that udev sets its defaults > based on LSB. I don't know whether or not LSB has anything to say about > keyboard layouts, or what the default keyboard layout should be. Apriori, there is no sensible default keyboard layout. -- 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: > 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
Peter Hutterer wrote: > 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
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
[rant] keeping policy in HAL
Beso wrote: > 2008/11/30 Kalle Vahlman <[EMAIL PROTECTED]>: >> 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. IMHO, there is still one thing very wrong with the HAL approach. I am talking about their upstream inconsistency concerning configuration in fdi files. Look, for example, on these bugs: http://bugs.kde.org/show_bug.cgi?id=133456 http://bugzilla.xfce.org/show_bug.cgi?id=2891 They are about the fact that removable storage devides are mounted with wrong options in popular desktop environments, and that there is no way to change it. Earlier, there were options like volume.policy.mount_option.*, that could be used to store mount options that should be used by default for certain filesystems. This is very important in order to get non-English characters in the filenames right. However, these options were deprecated because policy doesn't belong into HAL. 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? -- Alexander E. Patrakov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
