Date: Fri, 3 Oct 2014 17:38:34 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-stable@freebsd.org Cc: dumbell@FreeBSD.org Subject: Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally] Message-ID: <2C74DFEC-D943-4237-8988-B9657240EC21@dsl-only.net>
next in thread | raw e-mail | index | archive | help
I've not been using any tier 1 FreeBSD environments to compare/contrast = the below with: just powerpc and powerpc64, both only with PowerMacs. = This note is FYI in case the comparison/contrast with what others report = for tier 1 might have tier 1 implications. The XOrg context is 1.12. Context for this note: powerpc64/GENERIC64 using vt vs. sc for NVIDIA = 7800 GT's and Radeon X1950's on PowerMac G5 Quad cores, various = 10.?-???'s since this environment switched to vt. In this context = kern.vty=3Dvt is automatic and for an unmodified GENERIC64 sc is not = available (because of ps3 not supporting sc but being supported by an = unmodified GENERIC64). More build/configuration details at the bottom of = this message. Note: It takes a special GENERIC64 variant with ps3 disabled in order to = have sc available. Very recently [10.1.-BETA3] I've done that so I could = try sc. It takes kern.vty=3Dsc to get to the sc environment when it is = so added to GENERIC64. NVIDIA 7800 GT in that type of PowerMac G5: Nearly black text on black = background problems for vt console switching from Xorg/xfce4 but normal = text display for sc... For my context when vt is used with Xorg 1.12 and xfce4 (the only = context I've used) for the 7800 GT cards switching back to a console = window (Control/Option-Fn) displays nearly black text on a black = background. It is so near black that, depending on which display and the = lighting, I may or may not be able to read the text on careful = examination. Normally I can at least tell that something is being = displayed. But originally I though it was a black screen until one time = the lighting was such that I noticed the slight difference and = investigated further. The tail of Xorg.0.log after Control/Option-F2 = with "black on black" resulting ended up having no messages from after = startxfce4 finished starting: [ 81.598] (**) Apple Optical USB Mouse: (accel) keeping acceleration = scheme 1 [ 81.598] (**) Apple Optical USB Mouse: (accel) acceleration profile = 0 [ 81.598] (**) Apple Optical USB Mouse: (accel) acceleration factor: = 2.000 [ 81.598] (**) Apple Optical USB Mouse: (accel) acceleration = threshold: 4 [ 81.598] (II) Apple Optical USB Mouse: SetupAuto: hw.iftype is 4, = hw.model is 0 [ 81.598] (II) Apple Optical USB Mouse: SetupAuto: protocol is = SysMouse Returning to xfce4/Xorg and logging out added: [ 379.126] (WW) xf86EnableIO 7 [ 397.600] (II) UnloadModule: "kbd" [ 397.600] (II) UnloadModule: "mouse" [ 398.642] Server terminated successfully (0). Closing log file. so nothing unusual. (Nothing odd for the earlier parts either.) Logouts = also produce the "black on black" display issue for the console, even if = there was no prior switching to/from a console. sc does not have this problem for the 7800 GT's when I use kern.vty=3Dsc: = I can switch back and forth between Xorg/xfce4 and consoles or log out = just fine when using sc and the console displays end up normal/readable. = The tail of Xorg.0.log for an example of this ended up being: [ 163.091] (**) Apple Optical USB Mouse: (accel) acceleration profile = 0 [ 163.091] (**) Apple Optical USB Mouse: (accel) acceleration factor: = 2.000 [ 163.091] (**) Apple Optical USB Mouse: (accel) acceleration = threshold: 4 [ 163.091] (II) Apple Optical USB Mouse: SetupAuto: hw.iftype is 4, = hw.model is 0 [ 163.091] (II) Apple Optical USB Mouse: SetupAuto: protocol is = SysMouse [ 184.174] (WW) xf86EnableIO 7 [ 184.208] (**) Option "BaudRate" "1200" [ 184.209] (**) Option "StopBits" "2" [ 184.209] (**) Option "DataBits" "8" [ 184.209] (**) Option "Parity" "None" [ 184.209] (**) Option "Vmin" "1" [ 184.209] (**) Option "Vtime" "0" [ 184.209] (**) Option "FlowControl" "None" [ 212.917] (WW) xf86EnableIO 7 [ 515.033] (II) UnloadModule: "kbd" [ 515.034] (II) UnloadModule: "mouse" [ 516.427] Server terminated successfully (0). Closing log file. So for NVIDIA 7800 GT's on PowerMac's I'd expect that it is not any vt = vs. sc environment independent code that is the problem but something = specific to the vt context in some way. Radeon X1950 in the same sort of PowerMac G5, using vt as the example = context: Why I can not test console switching for such a Radeon = context... For 10.1-BETA3 the boot-time vt console display works for 1920x1200 but = not (usefully/readably) for 2560x1440. So the following notes are for a = 1920x1200 context. (10.1-BETA2 had different behavior and was usable for = 2560x1440 despite a temporary display oddity during booting. But I'm not = going down this path here. I'm pointing out a different XOrg issue.) My attempt to test a Radeon X1950 in such a PowerMac G5 shows that XOrg = does not get very far: [ 63.468] (WW) xf86EnableIO 7 [ 63.468] (WW) Falling back to old probe method for vesa [ 63.468] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card = support [ 63.468] (II) RADEON(0): TOTO SAYS 0000000090000000 [ 63.468] (II) RADEON(0): MMIO registers at 0x0000000090000000: size = 64KB [ 63.469] (II) RADEON(0): PCI bus 10 card 0 func 0 [ 63.469] (=3D=3D) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 63.469] (II) RADEON(0): Pixel depth =3D 24 bits stored in 4 bytes = (32 bpp pixmaps) [ 63.469] (=3D=3D) RADEON(0): Default visual is TrueColor [ 63.469] (**) RADEON(0): Option "NoAccel" [ 63.469] (II) RADEON(0): VGAAccess option set to FALSE, VGA module = load skipped [ 63.469] (=3D=3D) RADEON(0): RGB weight 888 [ 63.469] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 63.469] (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID =3D = 0x7240) [ 63.469] (--) RADEON(0): Linear framebuffer at 0x0000000098000000 [ 63.469] (II) RADEON(0): PCI card detected [ 63.469] (WW) RADEON(0): Failed to read PCI ROM! [ 63.469] (II) RADEON(0): Attempting to read un-POSTed bios [ 63.469] (WW) RADEON(0): Failed to read PCI ROM! [ 63.469] (WW) RADEON(0): Unrecognized BIOS signature, BIOS data will = not be used [ 63.469] (II) UnloadModule: "radeon" [ 63.469] (EE) Screen(s) found, but none have a usable configuration. [ 63.469]=20 Fatal server error: [ 63.469] no screens found The X1950 card works fine in Mac OS X 10.5 on the same PowerMac G5 Quad = core. (It is the only Radeon for a PCI Express based PowerMac that I = have access to.) My attempt to side step this with use of xf86-video-scfb and a matching = xorg.conf did not work either (note also the 'depth (32)' below vs. the = 'depth (24)' above, not just the 'Weight given (000)' below): [ 321.133] (II) LoadModule: "scfb" [ 321.134] (II) Loading = /usr/local/lib/xorg/modules/drivers/scfb_drv.so [ 321.134] (II) Module scfb: vendor=3D"X.Org Foundation" [ 321.134] compiled for 1.12.4, module version =3D 0.0.4 [ 321.134] ABI class: X.Org Video Driver, version 12.1 [ 321.134] (II) scfb: driver for wsdisplay framebuffer: scfb [ 321.154] (--) Using syscons driver with X support (version = 8595229351.252) [ 321.154] (--) using VT number 9 [ 321.154] (WW) Falling back to old probe method for scfb [ 321.154] scfb trace: probe start [ 321.154] (II) scfb(0): using default device [ 321.154] scfb trace: probe done [ 321.154] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card = support [ 321.154] scfb: PreInit 0 [ 321.154] (II) scfb(0): Using: depth (32), width (1920), height = (1200) [ 321.154] (**) scfb(0): Depth 32, (--) framebuffer bpp 32 [ 321.154] (EE) scfb(0): Weight given (000) is inconsistent with the = depth (32) [ 321.154] (II) UnloadModule: "scfb" [ 321.154] (EE) Screen(s) found, but none have a usable configuration. [ 321.154]=20 Fatal server error: [ 321.154] no screens found Additional PowerMac G5 FreeBSD configuration details for the current = 10.1-BETA3 status/tests: FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #31 r272167M: Tue Sep 30 = 22:50:33 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc /usr/src: $ svnlite info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 272167 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 272167 Last Changed Date: 2014-09-26 02:52:39 -0700 (Fri, 26 Sep 2014) $ svnlite status /usr/src ? /usr/src/.snap ? /usr/src/restoresymtable M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/conf/GENERIC64 M /usr/src/sys/powerpc/ofw/ofw_machdep.c The PowerMac G5's have some early-boot crash problems and the = db_script.c and ofw_machdep.c changes are for displaying some = information on screen for before any input is possible, some of it = during the crash handling and some of it before the potential crash. The GENERIC64 variant now in use disables ps3, adds sc, and has the DDB = and GDB options added. Those last two are associated with the above = before/during-early-crash information display and have been involved = from before I started disabling ps3 and adding sc. /etc/make.conf: $ more /etc/make.conf WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D (Most of the behavior has been tested on an SSD that only had the = WRKDIRPREFIX line and without the db_script.c/ofw_machdep.c changes and = all of it tested repeated in that context. The only reason for = WITHOUT_CLANG=3D is because clang's build was failing when = WITH_DEBUG_FILES=3D was present. powerpc/powerpc64 is not clang based as = of 10.1-BETA3 (or likely any time soon as far as I can tell).) $ more /boot/loader.conf verbose_loading=3D"YES" kern.vty=3Dvt (or with kern.vty=3Dsc instead as appropriate). I am copying my appropriate machine/device/driver-specific xorg.conf = file to /etc/X11/xorg.conf when I switch contexts that are not the same = video configuration. I do not bother listing them here. /usr/ports: $ svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 369514 Node Kind: directory Schedule: normal Last Changed Author: olgeni Last Changed Rev: 369514 Last Changed Date: 2014-09-29 03:44:00 -0700 (Mon, 29 Sep 2014) $ svnlite status /usr/ports ? /usr/ports/.snap ? /usr/ports/restoresymtable (I.e., no changes to the ports compared to r369514.) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C74DFEC-D943-4237-8988-B9657240EC21>