[Bug 51081] [ivb] i915 insertion hangs machine

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=51081


alupu at verizon.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




--- Comment #11 from alupu at verizon.net  2012-12-14 18:10:30 ---
(In reply to comment #10)
> Ok, so stuff seems to work as expected, safe that your monitor just doesn't
> like that 680x400 resolution you want.

Work as expected by whom, and WHY?  OK?

I've been using the _same_ monitor since day one.
It's a standard, solid, Samsung 2494.  I now switch it between the two
machines,
the "old" and the "new" since I started working on the new one.

> But since you force it, kernel complies and you get a black screen.

1.  Why not on the "old" one?  Same kernel.  Same basic hardware and HUI.
2.  Where have you heard about this strange (to put it delicately) "rule"?
(about when the kernel "complies" with an [unpleasant] "force" you get a blank
screen (and a dead keyboard and mouse too, I might add)).
If this so obvious and expected about kernel behavior (that only you know
about, BTW) then it should apply in all similar situations.

> Fyi you can also force modes with xrandr by adding
> new ones with xrandr --addmode. With the right mode bad wraparound (which I
> still think is simply a bug in fbconsole) is also gone.

If that were so, why is the original "wraparound" Bug 43167 --> 43239 still
buried deep (for more than a year) and UNRESOLVED.
Not even a half-hearted proposal for a successful workaround offered.
As everybody who's paid any attention to this original Bug handling, everything
stems from a bad kernel change I _proved_ and documented (at great effort and
against all odds) with a kernel bisection and all.
To this day kernel 3.0.20 (the last one standing) still works without all
these complications explained away by you (which BTW, do nothing other than
manage to insult a reader's intelligence.)

> So I'll close this as not a bug, it looks like what you've originally wanted to it simply something you're hw doesn't like too much.

My comments above demonstrate with facts, not invented "thoughts" for the
occasion by people who don't even bother to (or can) read a simple sentence
carefully, why this submission has to be reopened.

> If you _really_ want to get that 640x400 mode going I guess you need to change the timings (with xrandr --addmode) until you have something that works on your hw, and then use that on the cmdline.

No, I DO NOT "_really_ want to get that 640x400 mode".  NO NO NO.
I couldn't _really_ care less about what has to be on the command line.
ALL I ALWAYS WANTED has been SIMPLY,
when I exit the graphics mode to
1. get the 80x25 (back)
2. with CORRECT, as expected, wraparound !!

80x25, BTW, has been and will be the universal standard for text mode.
Proof of it, even now, on boot, the kernel starts the machine in 80x25
resolution.  It's amazing that this has to even come up as debatable.

And YES YES YES.  The current "nouveau" software (tested with an NVidia board
on
the same hw) meets all these BASIC "requirements" in stride:
80x25 and correct wraparound.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.