[Qemu-devel] [Patch] AltGr on vnc and adding extra keys with no compiling
Hi
On my keyboard Alt Gr is mapped to ISO_Level3_Shift. Using sdl it
worked fine without any modification, but using vnc I was unable to
use Alt Gr.
I added a line on /usr/share/keymaps/modifiers refering to my key:
ISO_Level3_Shift 0xb8
But, unfortunately it didn't work
Surfing on the qemu code, I realized that the ISO_Level3_Shitf wasn't
declared on the vnc_keysym.h file. So I added this line to that file:
{"ISO_Level3_Shift", 0xfe03}, /* ISO_Level3
And finally Alt Gr worked!
I think that it should be a good idea to allow the user to add keysym
manually by number and name. Instead of just name. This will allow to
add keysyms with no qemu recompiling. this can be done very easilly.
Just modfying get_keysym on keymaps.c
I attach a pacth with this two improves.
Regards and congratulations for a great program!
PS: Please CC me
--
Ricardo Ribalda
http://www.ii.uam.es/~rribalda/
--- qemu-old/keymaps/es Sun Dec 12 18:56:30 2004
+++ qemu-new/keymaps/es Tue Aug 08 23:41:55 2006
@@ -103,3 +103,58 @@
underscore 0x35 shift
dead_belowdot 0x35 altgr
dead_abovedot 0x35 shift altgr
+
+
+# Dead keys
+aacute 0x1e dead_acute
+Aacute 0x1e dead_acute shift
+eacute 0x12 dead_acute
+Eacute 0x12 dead_acute shift
+iacute 0x17 dead_acute
+Iacute 0x17 dead_acute shift
+oacute 0x18 dead_acute
+Oacute 0x18 dead_acute shift
+uacute 0x16 dead_acute
+Uacute 0x16 dead_acute shift
+yacute 0x15 dead_acute
+Yacute 0x15 dead_acute shift
+
+agrave 0x1e dead_grave
+Agrave 0x1e dead_grave shift
+egrave 0x12 dead_grave
+Egrave 0x12 dead_grave shift
+igrave 0x17 dead_grave
+Igrave 0x17 dead_grave shift
+ograve 0x18 dead_grave
+Ograve 0x18 dead_grave shift
+ugrave 0x16 dead_grave
+Ugrave 0x16 dead_grave shift
+
+adiaeresis 0x1e dead_diaeresis
+Adiaeresis 0x1e dead_diaeresis shift
+ediaeresis 0x12 dead_diaeresis
+Ediaeresis 0x12 dead_diaeresis shift
+idiaeresis 0x17 dead_diaeresis
+Idiaeresis 0x17 dead_diaeresis shift
+odiaeresis 0x18 dead_diaeresis
+Odiaeresis 0x18 dead_diaeresis shift
+udiaeresis 0x16 dead_diaeresis
+Udiaeresis 0x16 dead_diaeresis shift
+ydiaeresis 0x15 dead_diaeresis
+
+acircumflex 0x1e dead_circumflex
+Acircumflex 0x1e dead_circumflex shift
+ecircumflex 0x12 dead_circumflex
+Ecircumflex 0x12 dead_circumflex shift
+icircumflex 0x17 dead_circumflex
+Icircumflex 0x17 dead_circumflex shift
+ocircumflex 0x18 dead_circumflex
+Ocircumflex 0x18 dead_circumflex shift
+ucircumflex 0x16 dead_circumflex
+Ucircumflex 0x16 dead_circumflex shift
+
+acute 0x39 dead_acute
+grave 0x39 dead_grave
+diaeresis 0x39 dead_diaeresis
+asciicircum 0x39 dead_circumflex
+
--- qemu-old/keymaps.c Sun Apr 30 23:28:35 2006
+++ qemu-new/keymaps.c Tue Aug 08 23:39:58 2006
@@ -22,6 +22,7 @@
* THE SOFTWARE.
*/
+
static int get_keysym(const char *name)
{
name2keysym_t *p;
@@ -32,13 +33,26 @@
return 0;
}
+
+#define KEYMOD_SHIFT 0x01
+#define KEYMOD_CTRL 0x02
+#define KEYMOD_ALT 0x04
+#define KEYMOD_DEAD 0x08
+
#define MAX_NORMAL_KEYCODE 512
#define MAX_EXTRA_COUNT 256
+
typedef struct {
-uint16_t keysym2keycode[MAX_NORMAL_KEYCODE];
+uint16_t keycode;
+uint8_t keymod;
+int deadsym;
+} keydata_t;
+
+typedef struct {
+keydata_t keysym2keycode[MAX_NORMAL_KEYCODE];
struct {
int keysym;
- uint16_t keycode;
+keydata_t kdata;
} keysym2keycode_extra[MAX_EXTRA_COUNT];
int extra_count;
} kbd_layout_t;
@@ -50,6 +64,7 @@
char file_name[1024];
char line[1024];
int len;
+int upper;
snprintf(file_name, sizeof(file_name),
"%s/keymaps/%s", bios_dir, language);
@@ -82,17 +97,61 @@
if (*end_of_keysym) {
int keysym;
*end_of_keysym = 0;
+uint8_t keymod;
+int deadsym;
+
+keymod = 0;
+deadsym = 0;
+upper = 0;
+redo:
+if (upper==1){
+char *c;
+for(c=line;*c;c++)
+*c=toupper(*c);
+keymod |= KEYMOD_SHIFT;
+upper++;
+}
keysym = get_keysym(line);
if (keysym == 0) {
// fprintf(stderr, "Warning: unknown keysym %s\n", line);
} else {
const char *rest = end_of_keysym + 1;
int keycode = strtol(rest, NULL, 0);
+char *modifier;
+modifier = strtok (rest," ");
+modifier = strtok (NULL," ");
+while ( modifier != NULL) {
+if (!strcmp(modifier, "shift")) {
+keymod |= KEYMOD_SHIFT;
+} else
+if (!strcmp(modifier, "addupper")) {
+upper++;
+} else
+if (!strcmp(modifier, "ctrl")) {
+keymod |= KEYMOD_CTRL;
+} else
+if (!strcmp(modifier, "alt")) {
+
Re: [Qemu-devel] sh4 mov.b fix
> I think this patch is needed for proper implementation of > the sh4 mov.b @(disp,Rm),R0 instruction. and of course, I managed to send a reversed patch. That will teach me to send out things like that late at night. Here's the proper patch. Vince --- ./qemu-snapshot-2007-08-14_05/target-sh4/translate.c.orig 2007-08-24 01:37:56.0 -0400 +++ ./qemu-snapshot-2007-08-14_05/target-sh4/translate.c2007-08-24 01:48:47.0 -0400 @@ -879,10 +879,10 @@ gen_op_stw_T0_T1(ctx); return; case 0x8400: /* mov.b @(disp,Rn),R0 */ - gen_op_movl_rN_T0(REG(0)); - gen_op_movl_rN_T1(REG(B7_4)); - gen_op_addl_imm_T1(B3_0); - gen_op_stb_T0_T1(ctx); + gen_op_movl_rN_T0(REG(B7_4)); + gen_op_addl_imm_T0(B3_0); + gen_op_ldb_T0_T0(ctx); + gen_op_movl_T0_rN(REG(0)); return; case 0x8500: /* mov.w @(disp,Rn),R0 */ gen_op_movl_rN_T0(REG(B7_4));
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On 8/23/07, Dan Kenigsberg <[EMAIL PROTECTED]> wrote: > On Thu, Aug 23, 2007 at 12:09:47AM +0200, Andi Kleen wrote: > > > $ dmesg |grep -i hpet > > > ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) > > > ACPI: HPET id: 0x8086a301 base: 0xfed0 > > > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 > > > hpet0: 4 64-bit timers, 14318180 Hz > > > hpet_resources: 0xfed0 is busy > > > > What kernel version was that? There was a bug that caused this pre .22 > > > > I have vanilla 2.6.22.3 on that machine. Try: cat /sys/devices/system/clocksource/clocksource0/available_clocksource do you see HPET listed twice? Luca
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
On Friday 24 August 2007, Blue Swirl wrote: > I have now converted the ISA DMA devices (SB16, FDC), most PCI devices > and targets. > > gdma.diff: Generic DMA > pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA > pc_sb16_to_gdma.diff: Convert SB16 to GDMA > pc_fdc_to_gdma.diff: FDC > pc_dma_cleanup.diff: Remove unused functions > sparc_gdma.diff: Convert Sparc32 to GDMA > sparc32_dma_esp_le_to_gdma.diff: Convert ESP and Lance > sun4c.diff: Preliminary Sun4c (Sparcstation-1) support > pci_gdma.diff: Convert PCI devices and targets > > Any comments? The patches are a bit intrusive and I can't test the > targets except that they compile. Shouldn't the PCI DMA object be a property of the PCI bus? ie. we don't want/need to pass it round as a separate parameter. It can be inferred form the device/bus. Paul
[Qemu-devel] arm-linux-user infinite SIGSEGV looping
I've encountered what appears to be a race condition in arm-linux-user:
sometimes the program qemu is running will hang forever and sometimes it
will complete. After digging about there appears to be at least two
problems:
1) An initial cause of a SIGSEGV
2) The incorrect handling of the SIGSEGV
When #2 happens the symptom is an infinite loop in handling the SIGSEGV.
Using GDB I've stepped through the signal handling and have cause to
question a section of code that I would appreciate comments on. The
target-specific cpu-exec.c:handle_cpu_signal() appears to have a
different logical flow for arm than all other architectures and I wonder
if it is incorrectly implemented.
All architecture versions of handle_cpu_signal() will do one of four
things:
1) return 0 or 1 at the start for certain conditions
2) not return by calling (do_)raise_exception_err() which eventually
calls cpu_loop_exit()
3) not return by calling cpu_resume_from_signal() which eventually calls
longjmp()
4) call cpu_loop_exit() directly (which eventually calls longjmp())
After these various code paths there's usually a comment that says
"never comes here".
The arm target is an exception to the above outline.
raise_exception_err() has been comment disabled and the cpu_loop_exit()
is incorrectly indented giving a false impression that it will always be
called at the end of the function. I'm hypothesizing that for arm
handle_cpu_signal() incorrectly returns and doesn't break an infinite
loop.
Please comment!
Below is the questionable handle_cpu_signal():
static inline int handle_cpu_signal(unsigned long pc, unsigned long address,
int is_write, sigset_t *old_set,
void *puc)
{
TranslationBlock *tb;
int ret;
if (cpu_single_env)
env = cpu_single_env; /* XXX: find a correct solution for multithread */
#if defined(DEBUG_SIGNAL)
printf("qemu: SIGSEGV pc=0x%08lx address=%08lx w=%d oldset=0x%08lx\n",
pc, address, is_write, *(unsigned long *)old_set);
#endif
/* XXX: locking issue */
if (is_write && page_unprotect(h2g(address), pc, puc)) {
return 1;
}
/* see if it is an MMU fault */
ret = cpu_arm_handle_mmu_fault(env, address, is_write, 1, 0);
if (ret < 0)
return 0; /* not an MMU fault */
if (ret == 0)
return 1; /* the MMU fault was handled without causing real CPU fault */
/* now we have a real cpu fault */
tb = tb_find_pc(pc);
if (tb) {
/* the PC is inside the translated code. It means that we have
a virtual CPU fault */
cpu_restore_state(tb, env, pc, puc);
}
if( ret == 1 ) {
sigprocmask(SIG_SETMASK, old_set, NULL);
//raise_exception_err(env->exception_index, env->error_code);
} else {
/* we restore the process signal mask as the sigreturn should
do it (XXX: use sigsetjmp) */
sigprocmask(SIG_SETMASK, old_set, NULL);
cpu_loop_exit();
}
}
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Paul Brook wrote: On Friday 24 August 2007, Blue Swirl wrote: I have now converted the ISA DMA devices (SB16, FDC), most PCI devices and targets. gdma.diff: Generic DMA pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA pc_sb16_to_gdma.diff: Convert SB16 to GDMA pc_fdc_to_gdma.diff: FDC pc_dma_cleanup.diff: Remove unused functions sparc_gdma.diff: Convert Sparc32 to GDMA sparc32_dma_esp_le_to_gdma.diff: Convert ESP and Lance sun4c.diff: Preliminary Sun4c (Sparcstation-1) support pci_gdma.diff: Convert PCI devices and targets Any comments? The patches are a bit intrusive and I can't test the targets except that they compile. Shouldn't the PCI DMA object be a property of the PCI bus? ie. we don't want/need to pass it round as a separate parameter. It can be inferred form the device/bus. I agree. Moreover the DMA is bus specific so I don't see a need to add a generic DMA layer. Regards, Fabrice.
Re: [Qemu-devel] [PATCH][RFC] SVM support
This is a reworked version of the same patch, where I can now boot into a x86_64 Linux kernel. I rewrote all the access functions for the VMCB, so this time everything should work just fine on BE-machines. As suggested I moved the injection detection to translate.c, so the non-virtualized machine should be as fast as before (w/o svm support), while the virtual one got a speed boost from that as well. I removed the EIP hack and set EIP every time an interception occurs, so unlike the previous version this patch really should have no negative effect on speed any more. If any of the people on this list using SVM (kvm developers, maybe xen developers) could have a deep look into this I'd be really thankful. Some notes: - Saving and restoring CC_SRC and CC_DST is not correct as they do not belong to the real processor state. You must save and restore eflags correctly instead. - Avoid using macros when inline functions suffice. Regards, Fabrice.
[Qemu-devel] qemu Makefile.target configure vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:37:51 Modified files: . : Makefile.target configure vnc.c Log message: VeNCrypt basic TLS support, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.192&r2=1.193 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.152&r2=1.153 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.17&r2=1.18
[Qemu-devel] qemu vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:38:37 Modified files: . : vnc.c Log message: x509 certificate for server, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.18&r2=1.19
[Qemu-devel] qemu vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:39:10 Modified files: . : vnc.c Log message: x509 client certificate verification, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.19&r2=1.20
[Qemu-devel] qemu vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:39:57 Modified files: . : vnc.c Log message: Custom location for x509 cert paths, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.20&r2=1.21
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:40:38 Modified files: . : qemu-doc.texi Log message: Document all VNC authentication options, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.156&r2=1.157
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
> >> pci_gdma.diff: Convert PCI devices and targets > >> > >> Any comments? The patches are a bit intrusive and I can't test the > >> targets except that they compile. > > > > Shouldn't the PCI DMA object be a property of the PCI bus? > > ie. we don't want/need to pass it round as a separate parameter. It can > > be inferred form the device/bus. > > I agree. Moreover the DMA is bus specific so I don't see a need to add a > generic DMA layer. I can see use for a generic DMA interface. It has some nice possibilities for devices which can connect via a variety of busses and maybe for layering different busses within a system. However I don't know how well this will work in practice for the machines qemu currently emulates. Paul
Re: [Qemu-devel] qemu Makefile.target configure vnc.c
On Sat, 2007-25-08 at 01:37 +, Thiemo Seufer wrote: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Thiemo Seufer 07/08/25 01:37:51 > > Modified files: > . : Makefile.target configure vnc.c > > Log message: > VeNCrypt basic TLS support, by Daniel P. Berrange. Ah nice, was just testing this. Tried password and tls so far, both work well with gtk-vnc. Like being able to reconfigure them on the fly too. Great addition :) -- Matthew Kent <[EMAIL PROTECTED]> http://magoazul.com
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:34:19 Modified files: . : vl.c Log message: Avoid SEGV in IOHandler dispatch, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.330&r2=1.331
[Qemu-devel] qemu vl.c vl.h vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 01:35:38 Modified files: . : vl.c vl.h vnc.c Log message: Refactor VNC server setup API, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.331&r2=1.332 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.261&r2=1.262 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.14&r2=1.15
[Qemu-devel] qemu d3des.c d3des.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/25 02:09:50 Added files: . : d3des.c d3des.h Log message: Actually add d3des implementation files. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/d3des.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/d3des.h?cvsroot=qemu&rev=1.1
