Max 2 and Raspberry Pi monitor mode

[sogaiu]

The following was enough to get it working here:

# uncommented the following line
hdmi_force_hotplug=1

# added the following three
hdmi_cvt=2200 1650 33
hdmi_mode=87
hdmi_group=2

Changes were made to config.txt and rebooting was enough to see it work.


P.S. There is a band of black at the top and a smaller one at the bottom, so perhaps some tweaking is in order.

[sogaiu]

Now to test mdp's Monitor mod

[sogaiu]

Apart from the black bands above and below, seems to be working.

mdp's Monitor Mod + script to interpret touch info via adb almost works -- it's almost because of the black bands (coordinates are off because of the black bands).

This was tested with a Raspberry Pi 2 running Raspbian (latest?) w/ some Android bits and python bits installed -- also /boot/config.txt was tweaked as mentioned before.

[mdp]

Originally Posted by sogaiu

mdp's Monitor Mod + script to interpret touch info via adb almost works -- it's almost because of the black bands (coordinates are off because of the black bands)

Have you tried:
-- adding the aspect ratio to the model (duly, since you can meet 1920x1080 or 1280x1024 etc.):

proportion = min( res_w_desktop / res_w_tablet , res_h_desktop / res_h_tablet );
offset_x = (res_w_tablet - (res_w_desktop/proportion))/2
offset_y = (res_h_tablet - (res_h_desktop/proportion))/2

-- the overscan configuration options of the Raspberry Pi (also, since you report also deal with asymmetry).

EDIT:
in fact, your get_mouse_and_factors() returns a "factor_x" and a "factor_y" ( return (mouse, host_x / (device_x * 1.0), host_y / (device_y * 1.0)) ) but there is actually a single proportion, since the Monitor software does not stretch.

[sogaiu]

Originally Posted by mdp

the overscan configuration options of the Raspberry Pi (also, since you report also deal with asymmetry).

They don't seem to have any effect -- I tried the four overscan_(left|right|top|bottom) settings with various values, but none of them appeared to have any effect (and this was with disable_overscan=1 commented out in config.txt). (On a side note, I did change the aspect ratio setting to be for 4:3, but this didn't appear to have any effect either.)

I was hoping to eliminate the bands so as not to have to tweak the script, but may be that's easier at this point.

As a data point, xrandr reports 1920x1200 when X is running.

For reference, I'm not sure what the maximum resolution capability of an RPi 2 is, but it appears someone managed at some point to get some RPi to do 4k:

https://www.raspberrypi.org/forums/v...p?f=38&t=79330

Attached should be edid.txt, obtained by doing:

$ tvservice -d edid.dat
$ edidparser edid.dat > edid.txt

Also of potential interest:

$ tvservice -m CEA
Group CEA has 14 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
(native) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
(native) mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive
mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive

and:

$ tvservice -m DMT
Group DMT has 20 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 5: 640x480 @ 72Hz 4:3, clock:31MHz progressive
mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive
mode 8: 800x600 @ 56Hz 4:3, clock:36MHz progressive
mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
mode 10: 800x600 @ 72Hz 4:3, clock:50MHz progressive
mode 11: 800x600 @ 75Hz 4:3, clock:49MHz progressive
mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
mode 17: 1024x768 @ 70Hz 4:3, clock:75MHz progressive
mode 18: 1024x768 @ 75Hz 4:3, clock:78MHz progressive
mode 21: 1152x864 @ 75Hz 4:3, clock:108MHz progressive
mode 28: 1280x800 @ 60Hz 16:10, clock:83MHz progressive
mode 32: 1280x960 @ 60Hz 4:3, clock:108MHz progressive
mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
mode 36: 1280x1024 @ 75Hz 5:4, clock:135MHz progressive
mode 47: 1440x900 @ 60Hz 16:10, clock:106MHz progressive
mode 48: 1440x900 @ 75Hz 16:10, clock:136MHz progressive
mode 51: 1600x1200 @ 60Hz 4:3, clock:162MHz progressive
mode 58: 1680x1050 @ 60Hz 16:10, clock:146MHz progressive
(prefer) mode 87: 2200x1650 @ 33Hz 4:3, clock:161MHz progressive

[sogaiu]

With the following in /boot/config.txt, now there is a smaller black band at the bottom only (there is no black band at the top, but not sure if the top is cut off):

hdmi_force_hotplug=1
hdmi_cvt=2200 1650 33 1
hdmi_group=2
hdmi_mode=87
max_framebuffer_width=2200
max_framebuffer_height=1650

So close!

[mdp]

Originally Posted by sogaiu

I was hoping to eliminate the bands so as not to have to tweak the script, but may be that's easier at this point.

As a data point, xrandr reports 1920x1200 when X is running.

Does the Monitor scale stretching the image, distorting it to another ratio?
Resolution 1920x1200 is a ratio of 16:10, while the resolution of the Max2 is a 16:12, implying one empty band of 1/12 on top and another at the bottom. (The ratio of the 2104x1560 Monitor is actually 4.0461538462:3 , but let us try not to think about it.)

If the script is not improved it will not cover resolutions outside 4:3 .

[mdp]

Originally Posted by sogaiu

According to display properties reported here, framerate in Hz is showing up as 33.0 Hz. Is that what other people see?

May be using something like the folllowing will get us somewhere:

I also connected my RPi to see into this thing.

It was a good idea to use hdmi_cvt, Sogaiu, but maybe you stopped short of defining the rest, after the framerate?

hdmi_cvt=<width> <height> <framerate> <aspect> <margins> <interlace> <rb> width width in pixels height height in pixels framerate framerate in Hz aspect aspect ratio 1=4:3, 2=14:9, 3=16:9, 4=5:4, 5=16:10, 6=15:9 margins 0=margins disabled, 1=margins enabled interlace 0=progressive, 1=interlaced rb 0=normal, 1=reduced blanking

[mdp]

Originally Posted by mdp

I also connected my RPi to see into this thing.

It was a good idea to use hdmi_cvt, Sogaiu, but maybe you stopped short of defining the rest, after the framerate?

I struggled a bit unti I realized I was using 1920x1200 - setting the /boot/config.txt is just one half of it.

EDIT: up to now, the only HDMI modes I found that work in the boot config are 2200x1650@33 and 2200x1650@30.
Nonetheless, the resolution remains 1920x1200.
Using `tvservice -m "DMT 87" ` (the only resolution available apart from a "lower and safe" one seem to be that specified in /boot/config.txt) only blanks the screen, that comes back to 1920x1200 with an [ESC].

Experimenting would be easier if there was a command to try different settings...
Maybe
` fbset -depth 16 -xres 2200 -vxres 2200 -yres 1650 -vyres 1650 ; xrefresh `
?

Sogaiu, have you tried 'hdmi_ignore_edid'? Also Everalm toyed with it. Remember, Everalm went up to eleven.

And what about
`sudo raspi-config` ; Advanced Options > Resolution
?

(I cannot test right now)

By the way, I did not remember the Raspberry PI to be so fast! It would do miracles, if only it had a fast storage (much faster than the SD).

[sogaiu]

Originally Posted by mdp

but maybe you stopped short of defining the rest, after the framerate?

I tried filling in all of the hdmi_cvt= values, but without noticeable success. I may come back to try that -- perhaps after or along with hdmi_timings=.

What made a significant difference here to escape from 1920x1200 were the two max lines (how poetic):

max_framebuffer_width=2200
max_framebuffer_height=1650

FWIW, I get the following output for fbset now (and only a small band at the bottom edge):

mode "2200x1650"
geometry 2200 1650 2200 1650 32
timings 0 0 0 0 0 0 0
rgba 8/16,8/8,8/0,8/24
endmode

I also tried:

hdmi_ignore_edid=0xa5000080

as well as the spinal tap magic, but didn't notice any difference.

[sogaiu]

If you don't mind a small black band at the bottom of the screen, the following set up seems to work pretty well (except for some reason drag-and-drop). Note the use of 2104 and 1560 (not 2200 and 1650).

/boot/config.txt:

hdmi_cvt=2104 1560 30 1
max_framebuffer_width=2104
max_framebuffer_height=1560
hdmi_group=2
hdmi_mode=87
hdmi_force_hotplug=1

(It's probably obvious, but rebooting is necessary after the above are incorporated into /boot/config.txt)

To test the touch capability of the Max 2 with the RPi (tested w/ RPi 2 running Raspbian 9), relevant pieces from the 'Onyx Boox as monitor' thread include:

mdp's Monitor Mod 2 (post 409)
the script 'onyx-monitor-move-pointer-hack-6.py' (post 432)

1. Install the Monitor Mod 2 apk on the Max 2 and save the script on the RPi.

2. Shave some yaks by doing some installation on the RPi

sudo apt-get update
# pre-requisites for the script
sudo apt-get install -y android-tools-adb android-tools-fastboot
sudo pip install pyuserinput
# virtual keyboard if desired
sudo apt-get install florence at-spi2-core # or just matchbox-keyboard

3. On the Max 2, ensure Settings -> Developer Options -> USB debugging is enabled

4. Connect the RPi and the Max 2 with appropriate USB and HDMI cables.

5. Get adb running on the RPi with:

adb devices

and verify the Max 2 is visible via the output.

6. Answer 'OK' or equivalent to the dialog box that should pop up on the Max 2's screen about allowing the USB debugging connection.

7. Start Monitor Mod 2 on the Max 2 -- I often see a dialog box on the screen about power consumption (to which I typically answer 'OK'), but most of the time I haven't noticed power issues.

8. The script on the RPi needs to be coaxed a bit if using it from outside of X with something like:

DISPLAY=":0.0" python2 onyx-monitor-move-pointer-hack-6.py

9. It helps when testing the touch capability to have the RPi running X and showing it -- with that set, try clicking on things with the stylus (e.g. in Raspbian, there are typically some icons along the top edge of the screen). Another test might be to launch 'florence' or 'matchbox-keyboard' and try stylus-entering some text via either of those virtual keyboards.

Some observations:

-The instructions were partially from memory, so there are likely some errors...

-Double-clicking doesn't seem to work as well as when connected to a PC running some Linux distribution

-Haven't had luck with drag and drop yet -- at least via the title bars of windows. Work-around: with focus on the window one wants to move, type alt-space, select 'Move' from the resulting pop-up menu, and then drag the window with the stylus to the ultimate destination.

-It was helpful to have a physical keyboard attached while testing as well as SSH access to the RPi -- but if you've read this far, you probably knew those kinds of things already

[mdp]

Originally Posted by sogaiu

/boot/config.txt:

Are you sure that's all you have in the /boot/config.txt ?
At some point, I did not have the screen any more - even though I would have sworn that I used modifications to the configuration which worked before -, and again replacing everything with your config lines does not bring effect. "Insert HDMI cable" etc.
A `find . -mtime 2 ` reveals only the expected files, and nothing related to the display. Puzzling.
A piece of the /boot/config.txt should be missing, or the HDMI of my RPi3 is malfunctioning (strange).

[mdp]

Originally Posted by mdp

By the way, I did not remember the Raspberry PI to be so fast! It would do miracles, if only it had a fast storage (much faster than the SD).

Incidentally: a Linux desktop directly using the Max2 would work who0oom (the Max2 being doublish the power of a RPi3).

[sogaiu]

Originally Posted by mdp

Are you sure that's all you have in the /boot/config.txt ?

When I run:

grep -v '^#' /boot/config.txt

apart from empty lines, I get:

hdmi_cvt=2104 1560 30 1
max_framebuffer_width=2104
max_framebuffer_height=1560
hdmi_group=2
hdmi_mode=87
hdmi_force_hotplug=1

Note that this is with a RPi 2 Model B running Raspbian 9. Is it possible some defaults differ for other hardware / distribution combinations?

[sogaiu]

Originally Posted by mdp

Incidentally: a Linux desktop directly using the Max2 would work who0oom (the Max2 being doublish the power of a RPi3).

On a related note, I've not tried the following yet, but perhaps it's worth an attempt at some point:

https://github.com/xeffyr/termux-x-repository