Bug 1014066

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.

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 the javascript console to this bug; that will likely shed some light on what needs to be implemented.

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
> the javascript console to this bug; that will likely shed some light on what
> 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.

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

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 
/usr/libexec/vdsm/hooks/before_vm_start
#!/usr/bin/python

import os
import sys
import hooking
import traceback

'''
methods: auto_glz, auto_lz, quic, glz, lz, off
'''

domxml = hooking.read_domxml()
graphics = domxml.getElementsByTagName('graphics')[0]
image = domxml.createElement('image')
image.setAttribute('compression','quic')
graphics.appendChild(image)
hooking.write_domxml(domxml)
-%-

(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 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
> publicly
> followed up that I've seen.
> 
> Again, it shouldn't be a particularly hard problem to solve.

I found the one from march:
http://lists.freedesktop.org/archives/spice-devel/2013-March/012590.html

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.

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.