Auto fullscreen, or reason behind using resolution? about anthias HOT 7 CLOSED

Well, that's certainly a valid idea. The only thing is that I think that a hard-coded resolution is actually a feature rather than a bug.

The reason being that if you have a setup, you want to make sure you know what resolution you're running. Otherwise it would be difficult to produce content.

Now, if you bring up some content on the screen and the resolution is, let's say 1280x720 instead of 1920x1080, you might not immediately spot that if you have an auto-resizing setup. Sure, you could check the X11-logs, but chances are you won't and simply make an incorrect assumption.

Perhaps a better solution would be a hybrid of the two use a dynamic resolution, but displaying the resolution in the web interface.

from anthias.

Ok agree that it easier to spot the issue if you have a static resolution of the browser, but in the case of web pages I believe it is up to the page to detect, most of my setups uses javascripts on the client to correctly scale everything.

I have seen some issues with non matching size of the browser that was not directly visible (overscan enabled) and also if you change monitors or rotation it's a somewhat unnecessary step to manually change the configuration.

Would showing the resolution on the splash page possible the server status page be a acceptable solution?

from anthias.

The overlay issue is a separate issue altogether. I've struggled with that too, and I think the only way to fully solve that is to build a database of monitors and their required overlay (or even better, have that pushed up stream for auto detection). I have data from a few professional LG and Samsung monitors.

Showing it on the status-page might be a reasonable compromise, but we would still have to first retrieve the resolution (probably from parsing the X11-logs or some other X11 utility), and then put it in the database for permanent storage.

from anthias.

Or only use displays with full-pixel support to avoid the overscan issue. ;) (for me it was a bad display, that I since then have stopped using)

I was thinking that javascript that posts back to the server is the most portable.
A fallback could be to use the output from xrandr, on the other hand there must be python bindings available to do this in the viewer and "post" to the server.

If we want more information from x and recommended overscans etc then there is the XOrg logs, or maybe dumping monitor edid, but for me it is enough to just have auto resolution, and for the Raspberry Pi it is up to the user to configure possible overscan in /boot/config.txt

Will start work on a auto_resolution branch.

from anthias.

As I wrote in a comment to issue #7:

on a Raspberry Pi, with raspbian, we should be able to use the tvservice command to get resolution info.

pi@raspberrypi ~/screenly $ /opt/vc/bin/tvservice -s
state: HPD high|DVI mode|HDCP off|composite off (0x120016), 1920x1200 @ 60Hz, progressive

(sidenote: I noticed that on openelec tvservice is in /bin )

from anthias.

Good point @axel-b. That will definitely be easier than trying to parse it from the logs.

from anthias.

@vpetersson Thanks!
Would it be valid to remove the resolution parameter to uzbl as well as removing it from settings module and configuration file?

from anthias.