=== jono is now known as Guest46625
[05:48] <mlankhorst> g'morning
=== aissen_ is now known as aissen
=== soren_ is now known as soren
=== seb128_ is now known as seb128
[13:36] <penguin42> bug 1080674 is still triggering on current saucy (but seemed ok during the install?); what's the fix here?
[13:36] <ubottu> bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] https://launchpad.net/bugs/1080674
[13:37] <mlankhorst> penguin42: use 32-bits pixmaps
[13:38] <mlankhorst> and dont use cirrus, use hardware modesetting
[13:38] <mlankhorst> or qxl
[13:38] <penguin42> mlankhorst: ok but this is the behaviour of a standard install using the default settings in virt-manager
[13:39] <penguin42> mlankhorst: The default do-nothing case should work, whether that's by changing the default cases or whatever
[13:40]  * mlankhorst doesn't know what the default case is
[13:41] <penguin42> mlankhorst: Creating a VM in virt-manager gives you a cirrus video card+vnc, saucy/raring seem to then be using the cirrus X driver
[13:42] <mlankhorst> penguin42: in that case just fix it in the same way as for mdoesetting
[13:43] <mlankhorst> -           bppflags = Support24bppFb;
[13:43] <mlankhorst> +           bppflags = SupportConvert32to24 | Support24bppFb;        
[13:43] <mlankhorst> something like that
[13:44] <penguin42> you seem to have marked that a won't-fix
[13:44] <mlankhorst> because cirrus ddx driver shouldn't be used in raring or saucy
[13:44] <penguin42> mlankhorst: ok, so how do we make it so that it isn't used - because it still is
[13:45] <mlankhorst> I'm asking ogasawara in #ubuntu-devel, but I don't expect an answer right away
[13:45] <mlankhorst> however for raring it's too late, just do a sru if you really want to have the default fixed
[13:46] <tjaalton> 3.10 got qxl kms
[13:46] <penguin42> well I'm not too fussed about raring; but it would be nice for things to start working at some point
[13:46] <mlankhorst> I tested and modesetting was working for me at least
[13:46] <penguin42> tjaalton: Right if I explicitly select qxl it'll probably work
[13:48] <mlankhorst> oh right, on cirrus there's too little memory to do 1280xw/e unless you fixup the kernel
[13:48] <tjaalton> so the default is set in qemu-kvm?
[13:48] <mlankhorst> hm wait it should be enough, probably
[13:48] <penguin42> just tested; yeh qxl works
[13:48] <mlankhorst> qxl is using modesetting
[13:48] <penguin42> tjaalton: Probably libvirt/virt-manager I'm guessing
[13:48] <tjaalton> penguin42: oh, indeed
[13:49] <penguin42> tjaalton: To be fair it's probably a good safe bet, Cirrus works on pretty much every virtual machine, and virt-manager doesn't seem to have an entry for raring in it's 'select guest OS type' - which could be set to qxl as the default
[13:50] <penguin42> tjaalton: And even if we fix that there are plenty of other vm systems that present a cirrus
[13:51] <mlankhorst> *grumbls* stupid touch bug
[13:54] <penguin42> hmm qxl/spice is very weird on it's redraw - dragging a terminal back and forward does very odd things but eventually sorts itself out
[14:06] <mdeslaur> penguin42: you can use vmvga, that works for me
[14:07] <mdeslaur> penguin42: qxl still has issues when I tested it recently
[14:09] <penguin42> mdeslaur: It's working, a bit laggy, and I've just filed bug 1176920 which is just moans in it's log file; but certainly very usable
[14:09] <ubottu> bug 1176920 in xserver-xorg-video-qxl (Ubuntu) "lots of warnings during run in log file (zero width or height/out of video memory/bad bpp)" [Undecided,New] https://launchpad.net/bugs/1176920
[14:09] <mdeslaur> penguin42: one of the things I remember is that vts are broken with it
[14:10] <penguin42> mdeslaur: No, vts seem to be working ok
[14:10] <mdeslaur> hrm
[14:17] <Dandel> tjaalton, I thought of a reason to force the OpenCL library backport... it's approximately the same reason that the mesa librarys get a semi-permanent backport as libegl1-mesa-dev-lts-quantal and similar.
[14:25] <Dandel> anyways, without ocl-icd-opencl-dev ( source dep of ocl-icd-libopencl1 ) there is no way to get piglit to build with opencl support without requiring the amd or nvidia binary drivers. ( Since these both have libOpenCL since the icd core is not included in precise )
[14:27] <mlankhorst> the fact that it's doable, means nothing when nothing in precise cares or depends on it
[14:28] <Dandel> mlankhorst, some things actually do depend on it, but it winds up specifying nvidia or fglrx drivers as required
[14:29] <mlankhorst> but the precise packaging simply follows what we put in the releases
[14:30] <Dandel> then explain the lack of a library to go with opencl-headers.
[14:30] <Dandel> on all releases it specifies no dependencies, so you wind up with headers but nothing to link against.
[14:31] <mlankhorst> if saucy or raring has opencl, it might be easier to get it backported, but it's probably easier to not disable opencl
[14:31] <Dandel> they do.
[14:31] <Dandel> The specific package is ocl-icd-opencl-dev
[14:31] <mlankhorst> nothing in mesa is enabled though..
[14:32] <Dandel> it winds up installing ocl-icd-libopencl1.
[14:33] <Dandel> right now the galliumcompute is no where near complete. However, portable compute language ( pocl ) provides a cpu based implementation of OpenCL.
[14:34] <mlankhorst> if you want to request a backport, just request a normal backport to precise-backports first
[14:35] <mlankhorst> https://wiki.ubuntu.com/UbuntuBackports
[14:36] <Dandel> ok... although once that is fixed, piglit will see updates to enable OpenCL builds seeing as how if it's enabled now it'll break compile.
[15:14] <penguin42> curious; i've got raring, running a kvm with spice (running saucy with kvm running cirrus (with caucy) ) and the 2nd level guest is getting the background right - only seen one of the corruptions