6.2 and video mode problem

[emk]

I installed 6.2 on a test system that uses an LCD monitor that uses 1280x1024 at 60-70 Hz with a max horizontal sync rate of 64 kHz. This is a typical 19" LCD. On 6.1, the video was outside of the monitors sync range and I got no display. Changing the xorg.conf file fixed the display once UT was up (techniques already documented on this forum). The vga= mode needed to be changed on the grub boot line to get video during boot and shutdown.

On 6.2, the grub vga mode worked ok, but the Xserver configuration was out of sync range, just as with 6.1. This problem has become unsoluble: the xorg.conf file is no longer used when configuring the Xserver. There is a new file, unique to untangle (xorg-untangle-...??.conf) that drives the Xserver, and that file is re-created at every boot. Changes to xorg.conf were ignored. The standard resolutions did no go down far enough to ever allow me to see the whole virtual screen on my display. So configuration was very difficult.

So, how am I supposed to customize the video modes for X? Further, why should I? Why let Debian choose a video mode beyond the sync capability of most UT customers as a default? Why not set the Xserver to use a set of lower resolutions more typical for a monitor on a server rack.

Eric

[dmorris]

it only boots the untangle xorg file after the main xorg file fails.

you can read this code in /home/kiosk/.bashrc i think

[emk]

it only boots the untangle xorg file after the main xorg file fails.

The untangle xorg does not fail. It simply outputs using a resolution that the screen cannot display. The only resort is CTRL/ALT/- to reduce resolution. You just can't reduce it far enough.

Eric

[emk]

Just re-read your message and got the sense of it. You're saying the xorg.conf file is tried first. But that was not my experience yesterday. It appeared the untangle xorg file was tried first. I'll try it again later tonight.

I had tried the build out of the box before modifying the xorg.conf file and it failed to set a valid resolution on the monitor. Only then did I edit xorg.conf. So I think the problem that lots of people seem to be having with 6.1 is not fixed in 6.2, as is being advertised in this forum.

[NimRod]

So, how am I supposed to customize the video modes for X? Further, why should I? Why let Debian choose a video mode beyond the sync capability of most UT customers as a default? Why not set the Xserver to use a set of lower resolutions more typical for a monitor on a server rack.

Eric

I agree, I spent many hours with 6.1 on my Dells trying to get it to work. It is hard to sell a product that has video issues during the install.... I have been installing Untangle since the 4.X stage and have never had this many hardware problems. In fact, this isn't a hardware problem, but a software problem. I have used the same monitor for my Untangle installs for years and now it isn't supportted....? This is crap..

Nimrod

Love The Name.

[sky-knight]

I agree on this one NimRod... but this change wasn't Untangle's doing.

One of the issues facing the Untangle project is the fact that it doesn't develop most of the software we're using. It's simply trying to package existing 3rd party software into a sane format.

The current version of xorg is simply stupid... and we're stuck dealing with it. That is really the end of the complexity of the situation. It isn't like we can just revert back to the old version either. If we want the new kernel, and all the extra support for new network interfaces, SCSI controllers, and the like... we're stuck dealing with the video issues it brings.

Nothing is ever perfect, but at least when the platform is open source, we have a remedy.

[far182]

What's the solution for this then?

[sky-knight]

Wait for Xorg to collectively pull their heads out of their collective arses?

Other than that it's manual configuration of xorg. X issues aren't new... and they are always a PITA.

[fasttech]

I think the real question is, why were these upgrades pushed out with these types of issues and no warning. I thought the point behind beta testing was the hope to id issues like this before installations, networks and business continuity was destroyed.
Otherwise perhaps the developers sat in a meeting and said something like "Well gee, from testing we see that the upgrade will destroy 20% of the installations, but we've got to get this out now regardless, that sounds acceptable, let's run with it, maybe then the freeloaders will buy the propack after they get their nuts in the ringer by their employers/clients."
From what I can gather here, as long as your upgrade runs without issue, and your unit is headless, you shouldn't encounter any issues, otherwise have fun.

[sky-knight]

Well my ideal solution is to ditch the graphical local console anyway... The setup wizard is just run in firefox on the local box, why can't we just get to it via http management?

X is simply more trouble than it's worth. Not to mention a resource pig.

BUT... that is a rather fundamental change in the way UT works and I don't see it landing anytime soon. I'm just hoping the open source community that surrounds XOrg can find a way to fix this. Oddly enough XOrg on Debian specifically seems to be one of the largest pains. Doing some googling shows that Fedora, CentOS, SuSE, and several other distros are working fine.