Red Hat Bugzilla – Bug 1014066
[spice-html5] Windows desktop is turned upside down in spice-html5 console
Last modified: 2017-03-19 12:18:33 EDT
Created attachment 805842 [details]
Description of problem:
Windows desktop is turned upside down in spice-html5 console.
Version-Release number of selected component (if applicable):
windows 7 x64
Windows Guest Tools 3.2.15
client: rhel6.4, ff17
Steps to Reproduce:
1. have windows guest vm with tools and spice-html5/websocket-proxy setup
2. open spice-html5 console
console is upside down :)
uri - I'm aware we aren't supporting this formally, but is this a known issue? workaround?
I'm not running spice-html5 too much, and not much with a Windows machine.
I could reproduce the problem by connecting to a Win7 VM, with a qxl driver installed.
I noticed that uninstalling the qxl driver is a workaround.
Created attachment 809931 [details]
JS console log of SPICE HTML5 (VM: Win7_x64, with QXL drv)
(In reply to Jeremy White from comment #3)
> The spice-html5 client has been used primarily with XSpice; so this is a
> bug, and it is not unexpected. It would be helpful to post the results of
> needs to be implemented.
JS console log attached. Firefox 17.0.9 ESR, guest OS: Win 7 x64, QXL driver installed.
Created attachment 809942 [details]
screenshot - SPICE HTML5 console upside down
Screenshot of the upside down SPICE HTML5 console.
Sure enough; it's just unimplemented functionality in lz.js.
The fixme (Implement non top down support for lz_rgb) suggests
the issue. It may be possible to configure the spice server to not use lz
image compression, which would be a work around.
It also should be fairly straight forward to implement the code.
I'll poke if I get time, but that's not likely to be for a while, so others should feel free to have at it.
Note that if you fix this, that logs shows that there are likely a variety of other ways that the client doesn't work well with Windows. The variety of unimplemented messages, for example. A quick survey suggests that the bulk of those should be fairly easy to implement as well (and many should be harmless).
Jiri, can you try with a simple vdsm hook adding to the graphics section
<image compression='X'/> where X could be one of auto_glz, auto_lz, quic, glz, lz, off.
I did a quick search based on what I saw in the spice-html5 log. Could this patch proposal be somehow related?
All compression methods do not help with upside down issue except 'quic'. With 'quic' it is OK. But when I click with mouse anyway, the mouse curses is lost - disappeared. So another issue...
# pwd ; cat 50_imagecompression
methods: auto_glz, auto_lz, quic, glz, lz, off
domxml = hooking.read_domxml()
graphics = domxml.getElementsByTagName('graphics')
image = domxml.createElement('image')
(In reply to Frantisek Kobzik from comment #8)
> Hi guys,
> I did a quick search based on what I saw in the spice-html5 log. Could this
> patch proposal be somehow related?
Yes, and a later one in March was better. Vincent and I exchanged private messages about that patch set; I had a number of concerns, and was asking him to address them. I also dropped the ball on him once :-/. He hasn't publicly
followed up that I've seen.
Again, it shouldn't be a particularly hard problem to solve.
(In reply to Jiri Belka from comment #9)
> All compression methods do not help with upside down issue except 'quic'.
> With 'quic' it is OK. But when I click with mouse anyway, the mouse curses
> is lost - disappeared. So another issue...
Yah, the log showed quite a few unimplemented messages; that's probably related to one of the missing cursor functions. That may be a bit trickier to implement; you don't get the kind of direct cursor control in a browser that Spice craves. That should probably be a separate bug, though.
(In reply to Jeremy White from comment #10)
> (In reply to Frantisek Kobzik from comment #8)
> > Hi guys,
> > I did a quick search based on what I saw in the spice-html5 log. Could this
> > patch proposal be somehow related?
> > http://lists.freedesktop.org/archives/spice-devel/2013-January/012093.html
> Yes, and a later one in March was better. Vincent and I exchanged private
> messages about that patch set; I had a number of concerns, and was asking
> him to address them. I also dropped the ball on him once :-/. He hasn't
> followed up that I've seen.
> Again, it shouldn't be a particularly hard problem to solve.
I found the one from march:
Is there something wrong with the patch that prevents using it? Can you remember?
The patch is not obviously wrong. I had some concerns about the set() method, which I think were my mistake.
I still have some concerns that there may be lz formats it doesn't handle; the:
if (lz_image.type == LZ_IMAGE_TYPE_RGBA)
lz_rgb32_decompress(u8, at, ret.data, LZ_IMAGE_TYPE_RGBA, false);
case, for example. There is a '* 4' in the code that carries an assumption about formats; I don't think that's right in type RGBA, and I'm not sure it's right for all lz formats.
But again, I'm not sure; it may be just fine. I was also being extra vigilant; Vincent is an obviously new-ish developer. Sadly, I probably scared him away with my vigilance :-(.
not converging, moving out of 3.4
Since it seems there is some compression method not implemented in spice_html5…and it gets triggered only when the SPICE drivers are installed….is there perhaps a way how to disable/change the method in qxl drivers? Might be good enough as a workaround...
Michal, you can disable some compression through qemu command-line. The <graphics type="spice"> libvirt element also accepts <image> and <jpeg> nodes to tweak that.
it's no good if it would be at VM start. Can it be changed on the fly, when we set the ticket maybe?
I was more thinking about the client "ignoring" the enhancements/optimizations done when the qxl driver is installed
I don't think this can be done dynamically
this bug won't fit into 3.5 release and is being deferred to a later release. If you deeply care about this bug and deserves to be re-evaluated please let me know
This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset.
Please set the correct milestone or add the flag.
I wonder if it still reproduces with 3.6...I haven't heard anyone complaining for a long time
I personally cannot reproduce it with Win 7 64bit and 3.6.5 WGT and 3.6.5 engine.
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
as per comment 36 it works on 3.6.5, closing as currentrelease.