| Summary: | vmware - xrandr lists 1x1 and 2x2 video modes | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Daniel Robbins <drobbins.daniel> |
| Component: | Driver/VMWare | Assignee: | Philip Langdale <xorgbugs.philipl> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | medium | ||
| Version: | 7.1 (2006.05) | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Daniel Robbins
2006-08-31 21:08:16 UTC
This is a necessary side-effect of implementing arbitrary mode guest resizing. If you look at the driver source you can see how this works. Right now, we haven't shipped the tools side of this, but when we do, you'll be able to resize the window and X will resize to exactly fit your window dimensions. Currently, it can only fit to pre-programmed modes. While you concern is valid, I would not expect a novice to be poking around with xrandr - I'd expect them to be resizing the window. Also, remember that most of the GUIs for randr filter the mode list (Certainly the GNOME one does). The ability to have the X display resize to the dimensions of the window sounds like a great capability. But it seems like you're saying that the 1x1 and 2x2 modes are necessary and will continue to exist even in the final version of the driver? Even if necessary to get the window/display resize code working, this still doesn't seem quite right. I'd like to look into a way to prevent bogus modes from being shown to the user. Since it is not your intent to offer a 1x1 or 2x2 mode to the user, it suggests that there is some limitation in the xrandr API that you are trying to work around. Might as well look at solving the root issue, so I'll see if Keith Packard might comment on this bug and offer some suggestions. Ideally, the xrandr API should do everything you need while at the same time give users a valid list of resolutions - ones intended to be actually used - at least, that is my understanding of how it should work. The best place to address this (I think) is in the xrandr API since then the solution automatically fixes the xrandr cmdline issue as well as any conceivable GUI mode selection tool that could be written. It's one thing if a GUI tool filters out low-resolution modes like 320x200 because it determines that the mode is too small for UI components to be displayed properly, but listing bogus modes - ones that you have no intention for the user to actually use for anything - that just seems like a hack. For now, I can comment out DynMode1 and DynMode2 in the vmware driver source to fix the problem for XFCE4 and hopefully that will take care of it with causing anything to blow up. Dropping this bug to P3/minor and I'll see if Keith might offer his opinion on this. Also, off-topic: freedesktop vmware bugs are still being assigned to nolan@vmware.com and I'm told that Nolan is no longer with VMWare - should probably be fixed. I imagine that Keith's response will be that this will be easy to do properly when his new randr+mergedfb stuff is done. :-) There's nothing particularly magical about 1x1 and 2x2. I could easily replace them with 640x479 or something larger, but the mode entries are required. The dynamic resizing code updates these modes as you resize the window (and you need two because randr doesn't allow you to switch to the same mode as you are in, even if the dimensions of the mode have changed). You should be able to create *new* modes on the fly and switch to those as the window changes size though. RandR certainly supports that. And, yes, the 'real' fix will be to use randr++ which permits arbitrary root window size setting. For now, I'll disable DynMode1 and DynMode2 (set them to null) in vmware.c in the vmware driver I'll be using for a product I'm working on. Philip, should this be a decent interim solution with no adverse effects? (I've tested it here, and it seems to work fine and solve the problem.) I'm currently working on a patch to lazily allocate the dynamic modes, so they won't be in the list until you start using the VMWARECTRL extension to request modes. I have committed the change to the git repository. Note that the current GIT head is not compatible with xorg 7.0, so if you're using that, you'll need to pull the diff and apply it to your older source - it will apply fine. Thanks for pointing out the problem, and to Keith for confirming that the lazy approach works. http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-vmware.git;a=commit;h=0850feff708ded63c27dc938ca4b9b8fcbed122b |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.