Ruslan Kabatsayev

RAW capability is detected incorrectly (gives false negative on some phones)

It certainly still exists. I've just run Xubuntu 19.04 Live image in QEMU, downloaded bochs-20191112, and the problem still exists, unless I add x86_64 to the list of expected "good" host CPUs. Like here, but I'm not sure whether this will work completely because I keep getting "autoheader failed with exit status 1" from autoreconf -fi regardless of whether I apply this patch: --- aclocal.m4.orig 2019-11-14 06:16:06.239601367 +0000 +++ aclocal.m4 2019-11-14 06:16:08.767637675 +0000 @@ -2279,7 +2279,7...

Exposure bracketing results in brightness banding in the frames 0 & 1 (which go after frame 2)

I don't quite understand what I should try to do. To apply this same change? But I already did this right before reporting this. Anyway, the generation by autoconf shouldn't be a problem: I see this chunk present in aclocal.m4, which seems to be one of the sources for configure script. It seems though my original patch is not quite correct: the correct fix seems to be to add x86_64 to the case $host_cpu in alpha* | hppa*... list. Judging by the comment, that file_magic part should be used only for...

Dithering is actually not hard with GLSL. Here's an example of how one can implement it (this is not optimized, just something which does work in that project): https://github.com/10110111/precomputed_atmospheric_scattering/commit/40717f26bf8ead015c01af7a304cb9474d022e0f

Plugins aren't compiled as shared objects on Kubuntu 14.04 x86-64

OK, I've managed to get disassembly from disasm as well as disassembly of the current instruction with this change: Index: bx_debug/dbg_main.cc =================================================================== --- bx_debug/dbg_main.cc (revision 13290) +++ bx_debug/dbg_main.cc (working copy) @@ -2079,7 +2079,7 @@ if (bx_dbg_read_linear(which_cpu, BX_CPU(which_cpu)->guard_found.laddr, 16, bx_disasm_ibuf)) { -#if 1 +#if 0 unsigned ilen = bx_disassemble.disasm(IS_CODE_32(BX_CPU(which_cpu)->guard_found.code_32_64),...

Yeah, that works... sort of: Next at t=68983566136 (0) [0x00003115f084] 0023:0000000000100084 (unk. ctxt): vsqrtss xmm1, xmm2, xmm3 ; 62f16e0851cb <bochs:8> disasm/5 0000000000100084: ( ): bound esi, (bad) ; 62f1 0000000000100086: ( ): outsb dx, byte ptr ds:[esi] ; 6e 0000000000100087: ( ): or byte ptr ds:[ecx-53], dl ; 0851cb 000000000010008a: ( ): nop ; 90 000000000010008b: ( ): int3 ; cc I.e. disasm_current indeed works normally, but not disasm_command. I suppose it's just a way to enable the...