Gerd Hoffmann writes:
> Lets go with v2 of this patch.
>
> There are some codestyle issues in the patch (and the others too),
> please fix them them (scripts/checkpatch.pl helps), then resend the
> whole series.
OK. I'll send with new thread, not this thread.
--
OGAWA Hirofumi
Hi,
> OK. For cleaner (purpose is separation of curses code), I introduced
> hw_text_update_cb() interface (looks like possible to use text data for
> other than curses interface too). But you may feel this is overkill.
Waded through the code a bit. The whole text interface isn't cleanly
abstr
Gerd Hoffmann writes:
>> > Also you don't need a init function, you can simply init the array with
>> > c99 initializers:
>> >
>> > chtype vga_to_curses[256] = {
>> > [0x04] = ACS_DIAMOND,
>> > [ ... ]
>> > };
>>
>> This is not possible, because ACS_* is not constant (initialized by
>> r
Gerd Hoffmann writes:
>> (E.g. qemu is going to extend to use this for other purpose?)
>
> Unlikely. In theory other ui frontends could support vga text mode that
> way. But text mode is a dying relic, people use either graphics or a
> serial console these days, so I don't expect that to happen
> > Also you don't need a init function, you can simply init the array with
> > c99 initializers:
> >
> > chtype vga_to_curses[256] = {
> > [0x04] = ACS_DIAMOND,
> > [ ... ]
> > };
>
> This is not possible, because ACS_* is not constant (initialized by
> reading from termcap or such).
Ah,
Hi,
> From this call paths, graphic_hw_text_update() => console_write_ch() =>
> ->text_update() path is only used for -curses mode. What do you think?
Oh, right, text mode curses update and text mode framebuffer rendering
take completely separate code paths. Completely forgot that, I rarely
lo
OGAWA Hirofumi writes:
>> Ok, curses and gtk can't be active at the same time. But for curses and
>> vnc it is possible (qemu -curses -vnc :$display), and you probably get a
>> dissorted vga text mode over vnc then.
>>
>> I think the mapping should happen in the curses code, when curses
>> updat
Gerd Hoffmann writes:
>> vga_to_curses[] is filled by curses_setup(). So if no -curses option, I
>> think it should have no change to behavior. (BTW, there is no common
>> section like kernel in qemu build, right? i.e. no need initializer to
>> global value.)
>
> Ok, curses and gtk can't be acti
On Do, 2015-10-15 at 08:58 +0900, OGAWA Hirofumi wrote:
> Gerd Hoffmann writes:
>
> > On Mi, 2015-10-14 at 20:37 +0900, OGAWA Hirofumi wrote:
> >> This converts vga code to curses code in console_write_bh().
> >>
> >> With this changes, we can see line graphics (for example, dialog uses)
> >> co
OGAWA Hirofumi writes:
> Gerd Hoffmann writes:
>
>> On Mi, 2015-10-14 at 20:37 +0900, OGAWA Hirofumi wrote:
>>> This converts vga code to curses code in console_write_bh().
>>>
>>> With this changes, we can see line graphics (for example, dialog uses)
>>> correctly.
>>
>> But it breaks line gra
Gerd Hoffmann writes:
> On Mi, 2015-10-14 at 20:37 +0900, OGAWA Hirofumi wrote:
>> This converts vga code to curses code in console_write_bh().
>>
>> With this changes, we can see line graphics (for example, dialog uses)
>> correctly.
>
> But it breaks line graphics in vga text mode on gtk I sus
On Mi, 2015-10-14 at 20:37 +0900, OGAWA Hirofumi wrote:
> This converts vga code to curses code in console_write_bh().
>
> With this changes, we can see line graphics (for example, dialog uses)
> correctly.
But it breaks line graphics in vga text mode on gtk I suspect?
cheers,
Gerd
[meta-comment]
On 10/14/2015 05:37 AM, OGAWA Hirofumi wrote:
> This converts vga code to curses code in console_write_bh().
>
You sent your message with deep threading, with each message a reply to
the previous, resulting in:
0/3
+ 1/3
+ 2/3
+ 3/3
and when someone replies, a mail client
This converts vga code to curses code in console_write_bh().
With this changes, we can see line graphics (for example, dialog uses)
correctly.
Signed-off-by: OGAWA Hirofumi
---
include/ui/console.h | 11 ++-
ui/curses.c | 42 ++
2 fi
14 matches
Mail list logo
