Wait!
This doesn't reply to my question, I never talked about VNC servers or
clients.
If you want replies about a similar but quite different matter, post a new
topic, don't "takeover" the mine.
Thank you,
--
Gaetano Sferra
_
Per
On Mon, 31 Jul 2006 12:13:14 +0200, Eric Hameleers wrote:
> Are other people with international keyboards having these issues as well?
> What is the difference with the old RFB patch that the currently built-in
> VNC server handles differently?
The old VNC patch uses LibVNCServer which is a deriv
I've been following the thread about disk data consistency with some
interest. Given that many IDE disk drives may choose to hold data in their
write buffers before actually writing it to disk, and given that the
ordering of the writes may not be the same as the OS or application expects,
the only
> Seems nobody here has any ideas either, which is kind of hard to believe. I
> don't know if this would work, but one idea I had was to divide up the gui
> timer into 260 slices (that's the # of scanlines the hardware expects), and
> simply update the hardware register that counts the scanlines th
Sorry, stupid hotmail default. According to the options I've now turned that
feature off, so hopefully that won't happen again, but there's no easy way
to verify it before sending that I can see in hotmail.
-Steve
From: Paul Brook <[EMAIL PROTECTED]>
To: "Steve Ellenoff" <[EMAIL PROTECTED]>
You misunderstand, I have no control over the running program. I didn't
write it, I don't have source code, and I surely wouldn't have used a
polling mechanism for determining the vblank as you suggested.
My problem is that I wish to run this program through qemu. I've made a
bunch of hardware
Is it possible to run a real time OS under qemu? What changes would need to
be made?
Can it even be done?
The guest OS I'm trying to run sets the RTC System Timer 0 to a 0.25ms
interval (~4000Hz)!! The program I'm trying to run on it, expects this time
to be accurate, and as such, visually the
On 31/07/06, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Mon, Jul 31 2006, andrzej zaborowski wrote:
> On 30/07/06, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >Rik van Riel wrote:
> >> This may look like hair splitting, but so far I've lost a
> >> (test) postgresql database to this 3 times already.
I have occasionally found that I have killed off gdb, and had no way to
recover a debug session to QEMU. Also the detach/kill sequence does not
work correctly protocol wise in the QEMU gdb-stub. This patch addresses
these problems.
I implemented the serial protocol commands the same way as
On Mon, 31 Jul 2006 12:13:14 +0200, Eric Hameleers wrote:
> When I run qemu-0.8.2 with the VNC server enabled and then connecting to
> my QEMU's VNC server on a PC with a dutch keyboard layout, there is no
> way I can get the keyboard to function 100% correct.
Which keys aren't working for you?
> >>hw/mips_r4k.c:256: warning: pointer targets in passing
> >>argument 1 of ‘strcpy’ differ in signedness
> >
> > Compile with -Wno-pointer-sign. gcc4 isn't really supported anyway.
>
> Yes, I know ;) And yes, I know there are technical reasons
> for not supporting gcc4.
>
> But do you wan't to sa
Paul Brook wrote:
On Monday 31 July 2006 11:20, Dirk Behme wrote:
Fix warnings
hw/mips_r4k.c: In function ‘mips_r4kc_init’:
hw/mips_r4k.c:230: warning: pointer targets in passing
argument 3 of ‘load_elf’ differ in signedness
hw/mips_r4k.c:256: warning: pointer targets in passing
argument 1 of
Hello all,
It would seem to me that you could print better articles on
something of some sort of signifigance than a bunch of grown ball babies
crying over software. Enough already! Don't you people appreciate the things
that Fabrice has done? Leave the poor guy alone and grow up. Stop
On Monday 31 July 2006 11:20, Dirk Behme wrote:
> Fix warnings
>
> hw/mips_r4k.c: In function ‘mips_r4kc_init’:
> hw/mips_r4k.c:230: warning: pointer targets in passing
> argument 3 of ‘load_elf’ differ in signedness
> hw/mips_r4k.c:256: warning: pointer targets in passing
> argument 1 of ‘strcpy’
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 31 Jul 2006, Eric Hameleers wrote:
>
>
>>What is the difference with the old RFB patch that the currently
>>built-in VNC server handles differently?
>
>
> The old RFB patch uses the infrastructure of LibVNCServer, which has been
> tried and teste
Hi,
On Mon, 31 Jul 2006, Eric Hameleers wrote:
> What is the difference with the old RFB patch that the currently
> built-in VNC server handles differently?
The old RFB patch uses the infrastructure of LibVNCServer, which has been
tried and tested.
Unfortunately, Anthony decided to fix the is
Fix warnings
hw/mips_r4k.c: In function ‘mips_r4kc_init’:
hw/mips_r4k.c:230: warning: pointer targets in passing
argument 3 of ‘load_elf’ differ in signedness
hw/mips_r4k.c:256: warning: pointer targets in passing
argument 1 of ‘strcpy’ differ in signedness
--- ./hw/mips_r4k.c_orig 2006-07-31
On Mon, Jul 31 2006, andrzej zaborowski wrote:
> On 30/07/06, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >Rik van Riel wrote:
> >> This may look like hair splitting, but so far I've lost a
> >> (test) postgresql database to this 3 times already. Not getting
> >> the guest application's data to disk
Gaetano Sferra wrote:
> So nobody have ideas on how to solve the keyboard problem?
> I'm looking and seeking into the user's forum, there are similar
> questions but there aren't replies...
Hi,
I am having sort of similar problems with the keymapping. Rather than
coming up with an answer, I like
On 30/07/06, Jamie Lokier <[EMAIL PROTECTED]> wrote:
Rik van Riel wrote:
> This may look like hair splitting, but so far I've lost a
> (test) postgresql database to this 3 times already. Not getting
> the guest application's data to disk when the application calls
> fsync is a recipe for disaste
On Mon, Jul 31 2006, Jonas Maebe wrote:
>
> On 31 jul 2006, at 09:08, Jens Axboe wrote:
>
> >>Applications running on the host can count on fsync doing the
> >>right thing, meaning that if they call fsync, the data *will*
> >>have made it to disk. Applications running inside a guest have
> >>no
So nobody have ideas on how to solve the keyboard problem?
I'm looking and seeking into the user's forum, there are similar questions
but there aren't replies...
From: "Gaetano Sferra" <[EMAIL PROTECTED]>
Reply-To: qemu-devel@nongnu.org
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] AltGr ke
On 31 jul 2006, at 09:08, Jens Axboe wrote:
Applications running on the host can count on fsync doing the
right thing, meaning that if they call fsync, the data *will*
have made it to disk. Applications running inside a guest have
no guarantees that their data is actually going to make it
anyw
On Sat, Jul 29 2006, Rik van Riel wrote:
> Fabrice Bellard wrote:
> >Hi,
> >
> >Using O_SYNC for disk image access is not acceptable: QEMU relies on the
> >host OS to ensure that the data is written correctly.
>
> This means that write ordering is not preserved, and on a power
> failure any data
On Sat, Jul 29 2006, Paul Brook wrote:
> > Easy to do with the fsync infrastructure, but probably not worth
> > doing since people are working on the AIO I/O backend, which would
> > allow multiple outstanding writes from a guest. That, in turn,
> > means I/O completion in the guest can be done wh
On Fri, Jul 28 2006, Rik van Riel wrote:
> Anthony Liguori wrote:
>
> >Right now Fabrice is working on rewriting the block API to be
> >asynchronous. There's been quite a lot of discussion about why using
> >threads isn't a good idea for this
>
> Agreed, AIO is the way to go in the long run.
>
26 matches
Mail list logo
