Doom 2 seen running on an E-Ink display

[geekmaster]

After "all eink kindle" dithering, we will need touchscreen and button support too. And soon we will need 1024x758 Paperwhite support.

And I think we need landscape mode, for a wider field of view. IMHO.

[twobob]

Ah great news.

Okay well, I will try and figure out how it might be hacked into a running awesome

or a running awesome might be hacked into letting prboom run.

I suspect your "Ignore FB Blocking" will fix this issue though : )

[twobob]

[root@kindle root]# SDL_FBACCEL=0 SDL_VIDEODRIVER=fbcon SDL_DEBUG=1 SDL_MOUSE_DE
VICE=/dev/input/event2 SDL_JOYSTICK_DEVICE=/dev/input/event3 prboom -width 580 -
height 780 -nosound -file /mnt/us/usr/share/games/doom/prboom.wad

or something... it almost works. detects first click (brings up menu) then nothing.
This is all stuff I am just learning.

[twobob]

So. it would appear that x11vnc shows the ACTUAL FB content as opposed to the Black screen shown on the device. (Handy for testing...)

Also there is no eink artifacting (as it is displayed on an LCD screen, not handy for testing).

I got my first glimpse of what the working game will look like thanks to GM's tips. (and some gratuitous Buildrooting of supporting software)

So I'll share some screenshots. totally playable.

Exciting!

[twobob]

[root@kindle root]# x11vnc -viewonly -notruecolor -clip 592x780+4+10 \
-noxdamage -ncache 20

is a helpful set of commands for viewing

[root@kindle tmp]# SDL_FBACCEL=0 SDL_VIDEODRIVER=fbcon\
SDL_DEBUG=1 SDL_MOUSE_DEVICE=/dev/input/event4\ SDL_JOYSTICK_DEVICE=/dev/input/event3 prboom \
-width 592 -height 780 -nosound \
-file /mnt/us/usr/share/games/doom/prboom.wad

Also now using /usr/bin/lipc-set-prop -i -- com.lab126.volumd useUsbForNetwork 1 and /usr/bin/lipc-set-prop -i -- com.lab126.volumd useUsbForNetwork 0 to just get the job done via usb.

"Overally" much faster refresh, finally I can see the game "coming to life" on the device.

[twobob]

http://www.kernel.org/doc/Documentation/fb/fbcon.txt

This information is not directly applicable but I am going to play with ripping out the fbcon and maybe play with the rotation parameters if I can get the right tools built.

Spoiler:

C. Boot options

The framebuffer console has several, largely unknown, boot options
that can change its behavior.

1. fbcon=font:<name>

Select the initial font to use. The value 'name' can be any of the
compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,
SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8.

Note, not all drivers can handle font with widths not divisible by 8,
such as vga16fb.

2. fbcon=scrollback:<value>[k]

The scrollback buffer is memory that is used to preserve display
contents that has already scrolled past your view. This is accessed
by using the Shift-PageUp key combination. The value 'value' is any
integer. It defaults to 32KB. The 'k' suffix is optional, and will
multiply the 'value' by 1024.

3. fbcon=map:<0123>

This is an interesting option. It tells which driver gets mapped to
which console. The value '0123' is a sequence that gets repeated until
the total length is 64 which is the number of consoles available. In
the above example, it is expanded to 012301230123... and the mapping
will be:

tty | 1 2 3 4 5 6 7 8 9 ...
fb | 0 1 2 3 0 1 2 3 0 ...

('cat /proc/fb' should tell you what the fb numbers are)

One side effect that may be useful is using a map value that exceeds
the number of loaded fb drivers. For example, if only one driver is
available, fb0, adding fbcon=map:1 tells fbcon not to take over the
console.

Later on, when you want to map the console the to the framebuffer
device, you can use the con2fbmap utility.

4. fbcon=vc:<n1>-<n2>

This option tells fbcon to take over only a range of consoles as
specified by the values 'n1' and 'n2'. The rest of the consoles
outside the given range will still be controlled by the standard
console driver.

NOTE: For x86 machines, the standard console is the VGA console which
is typically located on the same video card. Thus, the consoles that
are controlled by the VGA console will be garbled.

4. fbcon=rotate:<n>

This option changes the orientation angle of the console display. The
value 'n' accepts the following:

0 - normal orientation (0 degree)
1 - clockwise orientation (90 degrees)
2 - upside down orientation (180 degrees)
3 - counterclockwise orientation (270 degrees)

The angle can be changed anytime afterwards by 'echoing' the same
numbers to any one of the 2 attributes found in
/sys/class/graphics/fbcon

rotate - rotate the display of the active console
rotate_all - rotate the display of all consoles

Console rotation will only become available if Console Rotation
Support is compiled in your kernel.

NOTE: This is purely console rotation. Any other applications that
use the framebuffer will remain at their 'normal'orientation.
Actually, the underlying fb driver is totally ignorant of console
rotation.

C. Attaching, Detaching and Unloading

Before going on on how to attach, detach and unload the framebuffer console, an
illustration of the dependencies may help.

The console layer, as with most subsystems, needs a driver that interfaces with
the hardware. Thus, in a VGA console:

console ---> VGA driver ---> hardware.

Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
from the console layer before unloading the driver. The VGA driver cannot be
unloaded if it is still bound to the console layer. (See
Documentation/console/console.txt for more information).

This is more complicated in the case of the framebuffer console (fbcon),
because fbcon is an intermediate layer between the console and the drivers:

console ---> fbcon ---> fbdev drivers ---> hardware

The fbdev drivers cannot be unloaded if it's bound to fbcon, and fbcon cannot
be unloaded if it's bound to the console layer.

So to unload the fbdev drivers, one must first unbind fbcon from the console,
then unbind the fbdev drivers from fbcon. Fortunately, unbinding fbcon from
the console layer will automatically unbind framebuffer drivers from
fbcon. Thus, there is no need to explicitly unbind the fbdev drivers from
fbcon.

So, how do we unbind fbcon from the console? Part of the answer is in
Documentation/console/console.txt. To summarize:

Echo a value to the bind file that represents the framebuffer console
driver. So assuming vtcon1 represents fbcon, then:

echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
console layer
echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
console layer

If fbcon is detached from the console layer, your boot console driver (which is
usually VGA text mode) will take over. A few drivers (rivafb and i810fb) will
restore VGA text mode for you. With the rest, before detaching fbcon, you
must take a few additional steps to make sure that your VGA text mode is
restored properly. The following is one of the several methods that you can do:

1. Download or install vbetool. This utility is included with most
distributions nowadays, and is usually part of the suspend/resume tool.
(have to check if this applies to us, I suspect not)

2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.

3. Boot into text mode and as root run:

vbetool vbestate save > <vga state file>

The above command saves the register contents of your graphics
hardware to <vga state file>. You need to do this step only once as
the state file can be reused.
(again, will look into this)


4. If fbcon is compiled as a module, load fbcon by doing:

modprobe fbcon

5. Now to detach fbcon:

vbetool vbestate restore < <vga state file> && \
echo 0 > /sys/class/vtconsole/vtcon1/bind

6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
you can unload it by 'rmmod fbcon'

7. To reattach fbcon:

echo 1 > /sys/class/vtconsole/vtcon1/bind

8. Once fbcon is unbound, all drivers registered to the system will also
become unbound. This means that fbcon and individual framebuffer drivers
can be unloaded or reloaded at will. Reloading the drivers or fbcon will
automatically bind the console, fbcon and the drivers together. Unloading
all the drivers without unloading fbcon will make it impossible for the
console to bind fbcon.

so as you can see not really 100% relevant I don't think (will check) but may give us another option for nerfing/fiddling with fbcon.

Anyway noted here for posterity
(and to be laughed at when I understand more and read it back)

EDIT: Seems like this is less relevant even than I thought. Ho hum : )

[root@kindle vtconsole]# cd vtcon0/
[root@kindle vtcon0]# ls
bind name power subsystem uevent
[root@kindle vtcon0]# cat name
(S) dummy device


lol

[geekmaster]

Originally Posted by twobob

... "Overally" much faster refresh, finally I can see the game "coming to life" on the device.

It will look better with dithering because your bottom 4-bits are being truncated by displaying true 8-bit framebuffer content (written by prboom) on a 4-bit eink screen without dithering, thereby losing important detail. But it is a great proof-of-concept.

[twobob]

exec /usr/local/sbin/dropbear -r /usr/local/etc/dropbear/dropbear_rsa_host_key

note to self for operation "Go-Round"

hmm.. does /etc/upstart/ get called during the DIAGS startup... probably not.
will have a play

[knc1]

Is the IP address the same in both "main" and "diags" ?
The host key will very likely be dependent on the IP address of the machine.
If so, you will need two host key files.
Not a big deal, just tossing out a possible heads-up.

[twobob]

hmm. yeah. I had a look. can only see one.

This next bit is not about what you are saying but...

I really don't have a handle on how the Diags startup works yet.
I can "get" it uses a different kernel, I fail to see how it could access a completely different set of files at runtime. thus I conclude it doesn't.

On the "computer" side I have noted that the ssh process "dies unexpectedly" via nautilus and have traced this down to a lack of "groups" support on the device so that is just ephemera. and could be fixed via a busybox update.

Also noted the .ssh/authorized_keys was not in place for the /home/root user.

Few other things... updated iptables to be more whorelike, dug around in upstarts and read through what scripts I could find.

I'll try an ENABLE_USBNET with an ENABLE_VPN and an ENABLE_DAIGS see where that gets me.

Thanks for the heads up, I'll see what shakes.

[knc1]

The file: ~/.ssh/authorized_keys is not created by the installation of sshd (at least not by the common versions of sshd used on *nix).

It is 'normal' that you have to create it the first time it is needed.

[twobob]

I knew that. : ) for once

[geekmaster]

Originally Posted by twobob

... hmm.. does /etc/upstart/ get called during the DIAGS startup... probably not.
will have a play

Diags doesn't use upstart (unless it changed since 5.0.0). Different startup scripts. I think it uses a single monolithic script with many upstart script snippets copied into it, as I recall.

[geekmaster]

Originally Posted by twobob

I knew that. : ) for once

Most of the diags+ssh hacks already have that key, and copying /usr/local between main and diags keeps the same key, to prevent host PC ssh duplicate key problems from 2 different keys with same IP address.

[twobob]

okay I will give it a test mate. thanks guys