NEW_XORG and vt(4) in stable branches

[Thomas Mueller]

On 02/12/14 20:43, John Baldwin wrote:

> Our current feeling is that we would like to not enable NEW_XORG by default
> for the packages for a given src branch until vt(4) has been merged to that
> branch.  We do not think that vt(4) needs to be enabled by default in the
> branch; just having it available as an option as it is in HEAD would be
> sufficient.  Our understanding is that merging vt(4) in its current-ish form
> to stable/10 and stable/9 is quite feasible and not a major nightmare.  We do
> not feel that it is necessary to merge to stable/8 as drm2 isn't merged to
> stable/8 either.  (Our assumption is that stable/8 will just stay with the old
> Xorg and the ports tree will have to support old Xorg until 8.x support in
> ports is EOL'd.)

> Does that sound sensible?

I am building HEAD amd64 and i386, intend to try X with vt(4) and vt_vga, meaning newcons.

I set up to build kernels for both newcons and syscons.

I also want to build stable/10, now at prerelease, delayed because I give priority to HEAD.

One question is whether vesa driver, with syscons, as a fallback, on stable/10 and 9, will enable NEW_XORG without nasty adverse effects.

I tried NEW_XORG on 9.2, or was it 9.1 (stable), trying to startx with either vesa or intel, hung the computer, I couldn't even run "shutdown -r now".

I had a mess of a time switching back to old Xorg.

I say 8.x is not worth the bother, but am put off by base.aa, base.ab, base.ac etc download files, and sysinstall.

Anyway, it sounds like too much trouble for 8.x approaching EOL.

With 9,x, I am quite satisfied to put sysinstall forever behind me.

I am considering upgrading from 9.2-STABLE directly to HEAD, skipping 10, after seeing how stable/10 and HEAD do on the other computer, where I would have no Internet access at all from FreeBSD 9.x due to bug in re(4) and lack of rsu(4).


Tom