Hi,
> > The problem is that when using relative mouses, we can't really assume that
> > there is any relationship between the absolute position of the host cursor
> > vs. the guest cursor, we should only operate in deltas and even then, we
> > probably want to dampen them to compensate for the g
On So, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2014-07-06 at 17:05 +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2014-07-06 at 16:46 +1000, Benjamin Herrenschmidt wrote:
> > > At this point, I"m tempted to just revert that commit. What do you
> > > think Gerd ?
> >
>
On Mon, 2014-07-07 at 06:56 +1000, Benjamin Herrenschmidt wrote:
> If we do it in the cirrus model itself, then we basically have to
> use the shadow pixmap always (can't ever share) and that means bringing
> back a pile of conversion functions to the VGA model that we were
> getting rid of (not ha
On Sun, 2014-07-06 at 14:09 +0100, Peter Maydell wrote:
> > The question is whether we can make it work that way (by basically
> > having grab and moving the host cursor) or do we really need to add
> a
> > layer for painting the cursor on top of the surface.
>
> I think this definitely needs to b
On 6 July 2014 12:23, Benjamin Herrenschmidt wrote:
> Well, it depends what you mean by the guest draws its own pointer ... we
> are in the specific case of cirrusfb HW cursor emulation which Gerd and
> I are trying to fix.
>
> Basically the guest doesn't draw anything. Gerd initial implementation
On Sun, 2014-07-06 at 12:13 +0100, Peter Maydell wrote:
> On 6 July 2014 12:08, Alexander Graf wrote
> > The guest's own acceleration can easily be non-linear, so we can't really
> > tell. However, FWIW we basically have 2 modes
> >
> > 1) absolute pointing device (usb tablet for example or vmmo
On 6 July 2014 12:08, Alexander Graf wrote
> The guest's own acceleration can easily be non-linear, so we can't really
> tell. However, FWIW we basically have 2 modes
>
> 1) absolute pointing device (usb tablet for example or vmmouse)
> 2) relative pointing device
>
> In case 1, we can keep us
On 06.07.14 12:13, Benjamin Herrenschmidt wrote:
On Sun, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote:
- With SDL, the cursor quickly goes bonkers, starts jumping around all
over the place, I'm not sure what exactly is going on here. It starts ok
but as soon as one does a too fast
On Sun, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote:
>
> - With SDL, the cursor quickly goes bonkers, starts jumping around all
> over the place, I'm not sure what exactly is going on here. It starts ok
> but as soon as one does a too fast movement, it's dead.
At least this one also
On Sun, 2014-07-06 at 17:22 +1000, Benjamin Herrenschmidt wrote:
> - With SDL, the screen colors are all wrong :-) It looks like a
> component is partially missing. Not sure what's up there, again,
> something else to debug. Everything has a blue tint (this is full emu on
> x86_64 host).
That on
On Sun, 2014-07-06 at 17:05 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2014-07-06 at 16:46 +1000, Benjamin Herrenschmidt wrote:
> > At this point, I"m tempted to just revert that commit. What do you
> > think Gerd ?
>
> I mean that hunk of the commit... I missed that the commit itself
> added
On Sun, 2014-07-06 at 16:46 +1000, Benjamin Herrenschmidt wrote:
> At this point, I"m tempted to just revert that commit. What do you
> think Gerd ?
I mean that hunk of the commit... I missed that the commit itself
added a whole lot more bound checking.
Cheers,
Ben.
On Sun, 2014-07-06 at 15:49 +1000, Benjamin Herrenschmidt wrote:
> We're basically tripping that test in cirrus_bitblt_rop_fwd_*
>
> if (dstpitch < 0 || srcpitch < 0) {
> /* is 0 valid? srcpitch == 0 could be useful */
> return;
> }
>
> Because when called from cirrus_bitb
On Sun, 2014-07-06 at 12:19 +1000, Benjamin Herrenschmidt wrote:
> One obvious issue: Your patch:
>
> gtk: update mouse position in mouse_set()
>
> Completely breaks cursor movement in NT4 (I haven't checked with other
> guests). It works fine without the patch. This is after cherry-picking
> on
On Sun, 2014-07-06 at 12:19 +1000, Benjamin Herrenschmidt wrote:
> I've started to look (and while at it added use of the dirty bitmap to
> catch changes to the HW cursor image just because it looked easy).
>
> One obvious issue: Your patch:
>
> gtk: update mouse position in mouse_set()
>
> Com
On Wed, 2014-07-02 at 14:12 +0200, Gerd Hoffmann wrote:
> https://www.kraxel.org/cgit/qemu/log/?h=rebase/console-wip
>
> Added a patch for hardware cursor support via dpy_cursor_define().
> Old hardware cursor code is still in, so in theory this gives you two
> pointers. In practice it only shows
On Wed, 2014-07-02 at 14:12 +0200, Gerd Hoffmann wrote:
> console/pixman bits are here:
>
> https://www.kraxel.org/cgit/qemu/log/?h=rebase/console-wip
>
> Added a patch for hardware cursor support via dpy_cursor_define().
> Old hardware cursor code is still in, so in theory this gives you two
>
On Mi, 2014-07-02 at 19:19 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2014-07-01 at 21:23 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-07-01 at 13:15 +0200, Gerd Hoffmann wrote:
> > > TCG works. Any workaround to make it fly with kvm too?
> > >
> > > And win98 actually uses the hardw
On Wed, 2014-07-02 at 19:19 +1000, Benjamin Herrenschmidt wrote:
> NT4 works a lot better without -enable-kvm :-) (file corruption, general
> bad behaviour...).
>
> I can confirm the cursor is missing in 16bpp with cirrus on NT4 as well,
> I'll play with it later this week or week-end, unless you
On Tue, 2014-07-01 at 21:23 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2014-07-01 at 13:15 +0200, Gerd Hoffmann wrote:
> > TCG works. Any workaround to make it fly with kvm too?
> >
> > And win98 actually uses the hardware cursor.
>
> Ah ok. I was trying to install NT4 here but was having pr
Il 01/07/2014 13:15, Gerd Hoffmann ha scritto:
Hi,
If you tell me what to look at, I legally own a Windows 98 CD (also NT4
but I have to dig it out) and can test it later this week.
/me has win98 too, that doesn't boot after install though.
Tried TCG? There is a timing loop that makes Wi
On Tue, 2014-07-01 at 13:15 +0200, Gerd Hoffmann wrote:
> TCG works. Any workaround to make it fly with kvm too?
>
> And win98 actually uses the hardware cursor.
Ah ok. I was trying to install NT4 here but was having problems,
the screen would go yellow and cirrus would stop displaying anything
Hi,
> >> If you tell me what to look at, I legally own a Windows 98 CD (also NT4
> >> but I have to dig it out) and can test it later this week.
> >
> > /me has win98 too, that doesn't boot after install though.
>
> Tried TCG? There is a timing loop that makes Win98 fail on too-fast
> compute
On Tue, 2014-07-01 at 10:26 +0200, Alexander Graf wrote:
>
> Windows NT 4 might use it. I remember that I had issues running NT4 with
> Cirrus emulation a while back.
Any location where one can find images legally ?
> >> Right. A quick fix would be to add a flag to force always using a shadow
>
On Tue, 2014-07-01 at 10:20 +0200, Gerd Hoffmann wrote:
> > Right. A quick fix would be to add a flag to force always using a shadow
> > surface and set it in cirrus ... I'm not sure anybody will notice the
> > performance difference.
>
> I suspect we can rip out hw cursor emulation and nobody wil
Il 01/07/2014 11:07, Gerd Hoffmann ha scritto:
On Di, 2014-07-01 at 10:31 +0200, Paolo Bonzini wrote:
Il 01/07/2014 10:26, Alexander Graf ha scritto:
Right. A quick fix would be to add a flag to force always using a shadow
surface and set it in cirrus ... I'm not sure anybody will notice the
On Di, 2014-07-01 at 10:31 +0200, Paolo Bonzini wrote:
> Il 01/07/2014 10:26, Alexander Graf ha scritto:
> >>
> >>> Right. A quick fix would be to add a flag to force always using a shadow
> >>> surface and set it in cirrus ... I'm not sure anybody will notice the
> >>> performance difference.
> >>
On Di, 2014-07-01 at 10:26 +0200, Alexander Graf wrote:
> On 01.07.14 10:20, Gerd Hoffmann wrote:
> > On Mo, 2014-06-30 at 22:32 +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote:
> >>>Hi,
> >>>
> From what I can tell, we only ever call the c
On 01.07.14 10:20, Gerd Hoffmann wrote:
On Mo, 2014-06-30 at 22:32 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote:
Hi,
From what I can tell, we only ever call the cursor drawing callback on
non-shared surfaces. Should I deduce that the HW curs
Il 01/07/2014 10:26, Alexander Graf ha scritto:
Right. A quick fix would be to add a flag to force always using a shadow
surface and set it in cirrus ... I'm not sure anybody will notice the
performance difference.
I suspect we can rip out hw cursor emulation and nobody will notice the
differe
On Mo, 2014-06-30 at 22:32 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > From what I can tell, we only ever call the cursor drawing callback on
> > > non-shared surfaces. Should I deduce that the HW cursor emulation simply
> > >
On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > From what I can tell, we only ever call the cursor drawing callback on
> > non-shared surfaces. Should I deduce that the HW cursor emulation simply
> > doesn't work when using shared surfaces ? Or is there another path I
> > hav
Hi,
> From what I can tell, we only ever call the cursor drawing callback on
> non-shared surfaces. Should I deduce that the HW cursor emulation simply
> doesn't work when using shared surfaces ? Or is there another path I
> have missed to handle it ?
Hmm. Looks like hw-cursor-on-shared-surfac
On Sun, 2014-06-22 at 12:10 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2014-06-21 at 15:37 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> > > If not -- then I prefer to play save and not use a vbe register to avoid
> > > ending up with two inc
On Sat, 2014-06-21 at 15:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> > If not -- then I prefer to play save and not use a vbe register to avoid
> > ending up with two incompatible bochs interface revisions. If you don't
> > like the pci confi
On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> If not -- then I prefer to play save and not use a vbe register to avoid
> ending up with two incompatible bochs interface revisions. If you don't
> like the pci config space option -- the mmio bar has plenty of free
> space left ;)
I'll f
Il 19/06/2014 14:33, Gerd Hoffmann ha scritto:
I'm thinking about splitting the conversion (for truecolor modes, still
need to think about how to do paletted modes best) into two steps:
First byteswap to bring the data into a format pixman can handle, then
feed into pixman for further conversion
On Di, 2014-06-17 at 12:42 +0100, Peter Maydell wrote:
> On 17 June 2014 12:24, Gerd Hoffmann wrote:
> > pl110 looks easy enough, so maybe I should just go convert it (and
> > sprinkle in comments) so there actually is a good example to follow.
> > Which arm board has one? Suggestions on how to t
On Mi, 2014-06-18 at 23:03 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-06-18 at 13:18 +0200, Gerd Hoffmann wrote:
> > The dispi interface has a versioned id too (VBE_DISPI_IDx) which we
> > could use too. Which makes sense IMO if we add the register to the
> > bochs dispi registers.
> >
>
On Wed, 2014-06-18 at 13:18 +0200, Gerd Hoffmann wrote:
> The dispi interface has a versioned id too (VBE_DISPI_IDx) which we
> could use too. Which makes sense IMO if we add the register to the
> bochs dispi registers.
>
> We could also place the register in pci config space, then indicate it
>
Hi,
> Any objection ? I'll spend some time in the next few days getting myself
> a bit more familiar with that pixman stuff (I need to fix the ppc vector
> stuff for LE in there anyway) and come up with patches.
Sounds good.
Have a look at
https://www.kraxel.org/cgit/qemu/log/?h=rebase/console
On Wed, 2014-06-18 at 01:05 +0200, Alexander Graf wrote:
> Given that, the prerequisite to that interface is to have a guest
> exposed register to flip the endianness in the first place. I think it
> makes most sense to settle on that register first, then talk about
> potential backwards compat
On 18.06.14 00:55, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 23:12 +0100, Peter Maydell wrote:
On 17 June 2014 22:32, Benjamin Herrenschmidt wrote:
Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
cleaner) to what I did in my patch which is when the pseries gu
On Tue, 2014-06-17 at 23:12 +0100, Peter Maydell wrote:
> On 17 June 2014 22:32, Benjamin Herrenschmidt
> wrote:
> > Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
> > cleaner) to what I did in my patch which is when the pseries guest calls
> > the hypervisor call to chan
On 17 June 2014 22:32, Benjamin Herrenschmidt wrote:
> Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
> cleaner) to what I did in my patch which is when the pseries guest calls
> the hypervisor call to change the interrupt endian mode, we notify VGA
> and switch its endian
On Tue, 2014-06-17 at 13:57 +0200, Gerd Hoffmann wrote:
> Ok, it is supposed to work this way:
>
> The virtual graphics card creates a DisplaySurface, which is a pixman
> image under the hood. There are basically two ways to do that:
>
> (1) Use qemu_create_displaysurface(). Allocates host m
On 17 June 2014 12:53, Benjamin Herrenschmidt wrote:
> On Tue, 2014-06-17 at 13:40 +0200, Greg Kurz wrote:
>> This conclusion was reached while discussing dump support where we
>> use LPCR_ILE, and I wanted to add a common helper to be used by
>> virtio. Please find the thread in the link below:
>
Hi,
> > Let pixman handle it? Well, except that pixman can't handle byteswapped
> > 16bpp formats. Too bad :(
>
> Right :) As I said, it's a trainwreck along the whole stack. I think my
> second patch is reasonably non-invasive and shouldn't affect performance
> of the existing path though.
On Tue, 2014-06-17 at 13:40 +0200, Greg Kurz wrote:
> This conclusion was reached while discussing dump support where we
> use LPCR_ILE, and I wanted to add a common helper to be used by
> virtio. Please find the thread in the link below:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2014-0
On 17 June 2014 12:24, Gerd Hoffmann wrote:
> pl110 looks easy enough, so maybe I should just go convert it (and
> sprinkle in comments) so there actually is a good example to follow.
> Which arm board has one? Suggestions on how to test it?
It's present in a number of them; the simplest one to
On Tue, 17 Jun 2014 20:09:18 +1000
Benjamin Herrenschmidt wrote:
> On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
> > There has been a discussion already about virtio endianness: relying on
> > a guest system wide setting such as LPCR_ILE has been strongly rejected
> > at the time... The con
Hi,
> > Let pixman handle it? Well, except that pixman can't handle byteswapped
> > 16bpp formats. Too bad :(
> Slight tangent, but is there an example in-tree of a framebuffer
> model which uses pixman for the pixel conversion? The -template.h
> stuff looks quite ugly, not to mention repetit
On Tue, 2014-06-17 at 12:45 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > The core issue stems from the fact that graphic stacks including X and a
> > number of other components along the way are terminally broken if the
> > framebuffer endianness doesn't match the guest endianness. We can
> > discuss
On 17 June 2014 11:45, Gerd Hoffmann wrote:
> Benjamin Herrenschmidt wrote:
>> What do you prefer ?
>
> Let pixman handle it? Well, except that pixman can't handle byteswapped
> 16bpp formats. Too bad :(
>
> In any case cleaning up the whole mess is overdue and doing that
> beforehand should sim
On Tue, 2014-06-17 at 11:19 +0100, Peter Maydell wrote:
> On 17 June 2014 11:09, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
> >> There has been a discussion already about virtio endianness: relying on
> >> a guest system wide setting such as LPCR_ILE h
Hi,
> The core issue stems from the fact that graphic stacks including X and a
> number of other components along the way are terminally broken if the
> framebuffer endianness doesn't match the guest endianness. We can
> discuss the historical reasons for that fact if you wish and we can
> discu
On 17 June 2014 11:09, Benjamin Herrenschmidt wrote:
> On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
>> There has been a discussion already about virtio endianness: relying on
>> a guest system wide setting such as LPCR_ILE has been strongly rejected
>> at the time... The consensus for virti
On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
> There has been a discussion already about virtio endianness: relying on
> a guest system wide setting such as LPCR_ILE has been strongly rejected
> at the time... The consensus for virtio is "device endianness is the
> endianness of the CPU that
On Tue, 17 Jun 2014 19:18:11 +1000
Alexey Kardashevskiy wrote:
> On 06/17/2014 03:36 PM, Paolo Bonzini wrote:
> > Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
> >> Thanks. I've tried the other approach of adding new functions which
> >> means no overhead (hopefully) for the non-swap ca
On 17.06.14 11:18, Alexey Kardashevskiy wrote:
On 06/17/2014 03:36 PM, Paolo Bonzini wrote:
Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
Thanks. I've tried the other approach of adding new functions which
means no overhead (hopefully) for the non-swap case and less invasive
changes
On 06/17/2014 03:36 PM, Paolo Bonzini wrote:
> Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
>> Thanks. I've tried the other approach of adding new functions which
>> means no overhead (hopefully) for the non-swap case and less invasive
>> changes to vga_template.c.
>>
>> Patch below. Wha
On Tue, 2014-06-17 at 07:36 +0200, Paolo Bonzini wrote:
> Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
> > Thanks. I've tried the other approach of adding new functions which
> > means no overhead (hopefully) for the non-swap case and less invasive
> > changes to vga_template.c.
> >
> >
Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
Thanks. I've tried the other approach of adding new functions which
means no overhead (hopefully) for the non-swap case and less invasive
changes to vga_template.c.
Patch below. What do you think ? This or the previous approach ? Then we
ca
On Tue, 2014-06-17 at 06:40 +0200, Paolo Bonzini wrote:
> Il 17/06/2014 05:07, Benjamin Herrenschmidt ha scritto:
> > I've come up with the proof of concept below which changes the various
> > line drawing functions in vga-template to select the right ld/st
> > function. However that adds a per-lin
Il 17/06/2014 05:07, Benjamin Herrenschmidt ha scritto:
I've come up with the proof of concept below which changes the various
line drawing functions in vga-template to select the right ld/st
function. However that adds a per-line test (overhead I can hear some
people shouting ! :-).
Sounds per
Hi folks !
WARNING: The patch below is NOT intended for merging for rather obvious
reasons in its current form :-)
So basically, we have a problem we need to solve in qemu powerpc related
to the emulated VGA, as I mentioned in an earlier mail yesterday.
The core issue stems from the fact that gr
66 matches
Mail list logo
