Re: Lack of /dev/vtvga0?
On Sat, Jun 23, 2018 at 12:11 AM, Chris H wrote: > I'm not clear if you're already possibly referring to this. But have > you tried sc(4) ( SysCons ). If you haven't tried already; > adding the following to your loader.conf(5) should give it to you: > > kern.vty=sc > > You can also include it in your custom kernel by adding this to your > KERNCONF > > devicesc > options SC_PIXEL_MODE # adds support for the raster text mode > > Hope this helps. Hi Chris, thanks for responding. Yup, I'm aware of using kern.vty to fall back to syscons, and SC_PIXEL_MODE to get framebuffer support via /dev/tty* devices. I actually have a port of the xf86-video-wsfb driver for scfb [0]. My question is actually specifically in regards to newcons/vt. By checking `dmesg` I can see that the libvt driver device vtvga0 is instantiated, but it's not mapped to any file in /dev/ which means I can't send it an IOCTL as I normally would. Or perhaps the problem is that with vt_vga loaded, IOCTLs to /dev/tty* devices only respond to CONSIO IOCTLs and not libvt or FBIO IOCTLs, which is how they would respond with SC_PIXEL_MODE and kern.vty=sc. Note that this is with hw.vga.textmode=0, which afaict per vt(4) is not the default, but at the same time does not seem to actually change anything. I believe the entire point of libvt was to abstract away the KMS drivers from the API framebuffer API and allow for dynamic switching of the backend driver without needing to switch to a different graphics provider or change the graphics library/framework/environment configuration, and indeed when loading the binary blobs for the test GPUs I have in the system, a /dev/fb0 magically appears, but there is no framebuffer device for the basic in-kernel VGA driver that is used until a more appropriate KMS driver has been loaded (if ever). [0]: https://github.com/neosmart/xf86-video-scfb/ Thanks, Mahmoud Al-Qudsi NeoSmart Technologies ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Lack of /dev/vtvga0?
Hello list, As I've mentioned in a previous message, I've been working on trying to get a proper graphics subsystem/desktop up and running under 12-CURRENT without any X components; something that was once possible a long time ago by using libvgl probably via SDL1.2 — an option that's been deprecated in SDL2 and isn't viable in all cases since libvgl doesn't support newcons/vt. I understand the limitations of the basic VGA driver (lack of hardware acceleration, current hard-coded 640x480x16 resolution) but I'm not clear on why the vt_vga driver does not make a framebuffer device available (vtvga0 is initialized, but there is no corresponding /dev/vtvga0). Isn't it possible to use vt_vga in pixel mode and directly write to the kernel console framebuffer? Any insight would be appreciated! Mahmoud Al-Qudsi NeoSmart Technologies ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] (validated against 50k+ i686 machines) for vmparam.h and vesa.c
Hello list,
NeoSmart Technologies has been using these patches to address issues in
production for live CDs that are used by end users on their own (generic)
hardware. We've validated the patches against well over 50k i686 machines,
(not fleet machines, each is more or less unique/random), running a patched
10.x kernel over many years (you can see the original date in the attached
patches).
The first (and perhaps more important) addresses a common bug on x86 hardware,
which results in the following error message combined with a panic at boot
time:
> Too many segments in the physical address map, giving up
The second addresses bug kern/162373 which causes the framebuffer
initialization to fail on certain graphics cards (AMD models seem particularly
affected) with EINVAL, caused by incorrect range checks (which are actually
prefaced with a "XXX: is this correct?" comment in the original source).
We have our own framebuffer-based Xorg display driver (xf86-video-scfb, see
[0]), so it was particularly important for us to have the framebuffer working
correctly. I know some (extensive) changes have been made to the framebuffer
with FreeBSD 11, so I'm not sure if the patch applies to code still in use or
not; I have not taken the time to check under 12-CURRENT.
[0]: https://github.com/neosmart/xf86-video-scfb
Thanks,
Mahmoud Al-Qudsi
NeoSmart Technologies
Patches follow.
--
>From 5829531f379d14939a4ec78e0d6647558cf4aa26 Mon Sep 17 00:00:00 2001
From: Mahmoud Al-Qudsi
Date: Thu, 17 Apr 2014 14:09:59 -0500
Subject: [PATCH] Increased VM_PHSYSSEG_MAX on i386
Trying to fix an error "Too many segments in the physical address
map, giving up" on boot that is seen on certain hardware
configurations when booting the i386 GENERIC kernel.
Previously attempted to work around this by setting hw.physmem to 3G,
but that only resulted in a kernel segfault instead of the too many
segments error.
Using VM_PHYSSEG_MAX set to 31, as taken from the AMD64 configuration,
initial testing seems to indicate this is OK for use on i386 as well.
---
sys/i386/include/vmparam.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/i386/include/vmparam.h b/sys/i386/include/vmparam.h
index 19cdd8e115eff..48e41a321d39b 100644
--- a/sys/i386/include/vmparam.h
+++ b/sys/i386/include/vmparam.h
@@ -74,7 +74,7 @@
* largest physical address that is accessible by ISA DMA is split
* into two PHYSSEG entries.
*/
-#define VM_PHYSSEG_MAX 17
+#define VM_PHYSSEG_MAX 31
/*
* Create two free page pools. Since the i386 kernel virtual address
--
--
>From b3af2d1ed4a63fe1a5d771ed3a052242250098d7 Mon Sep 17 00:00:00 2001
From: Mahmoud Al-Qudsi
Date: Thu, 17 Apr 2014 12:17:44 -0500
Subject: [PATCH] Fixed incorrect range checks in mmap of framebuffer
(kern/162373)
Implemented a fix for incorrect/invalid range checks in the vesa
framebuffer when attempting to mmap the framebuffer device. As
described in kern/162373, the original code contains a bug and will
incorrectly refuse to mmap at certain modes/resolutions because it
thinks the mmap length is out-of-range when it isn't.
Testing indicates that the revised framebuffer range check (mmap
offset is less than the window buffer size instead of the old check
that the offset is less than the window size minuse pagesize, which
really makes no sense) is the correct way to go.
---
sys/dev/fb/vesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/dev/fb/vesa.c b/sys/dev/fb/vesa.c
index 48067b6401fe6..c67b8f24e0d71 100644
--- a/sys/dev/fb/vesa.c
+++ b/sys/dev/fb/vesa.c
@@ -1631,7 +1631,7 @@ vesa_mmap(video_adapter_t *adp, vm_ooffset_t
offset, vm_paddr_t *paddr,
(adp->va_info.vi_flags & V_INFO_LINEAR) != 0) {
/* va_window_size == va_buffer_size/vi_planes */
/* XXX: is this correct? */
- if (offset > adp->va_window_size - PAGE_SIZE)
+ if (offset >= adp->va_info.vi_buffer_size)
return (-1);
*paddr = adp->va_info.vi_buffer + offset;
return (0);
--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SSH from WSL acts as if overwrite were enabled while actually inserting
> Have you tried it with a different shell? Such as /bin/sh rather than > fish? As I mentioned, > (regardless of the $TERM value under FreeBSD or the SSH shell I___m logging > into). It seems to be a lower level issue than that, perhaps termcap related. Mahmoud ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SSH from WSL acts as if overwrite were enabled while actually inserting
Hello all, Sorry about the confusing subject line, it’s the best I could think of to succinctly summarize the issue at hand. I’ve been running into an issue with FreeBSD from 10.x to 12-CURRENT and wanted to check with the mailing list before I bugged it to make sure it is a FreeBSD bug and not a WSL (the new Linux subsystem for Windows) bug. When I ssh into a FreeBSD host from a TERM=xterm-256color host that has no problem SSHing into Linux machines, the following behavior is observed (regardless of the $TERM value under FreeBSD or the SSH shell I’m logging into). Imagine the prompt currently reads as follows with the cursor at the space denoted by _ in the text below: user@freebsd % foo_bar If I type in ` foo` at this point, the prompt now reads user@freebsd % foo foo_ However, the _actual_ contents of the prompt are really user@freebsd % foo foo bar_ i.e. the _displayed_ prompt acted as if OVERWRITE were on, but the actual behavior is that INSERT was enabled. The actual behavior is the expected behavior, which is what the prompt should have shown. I do not experience this behavior when using, say, Putty instead of OpenSSH under WSL. I also do not experience this behavior when SSHing into a non-FreeBSD host. If this is not a FreeBSD bug, I’ll raise it with the WSL team who have proven to be very earnest in their attempts at fixing all compatibility issues via their GitHub presence. (A screenshot of the observed behavior, if it helps: http://i.imgur.com/k6hVtbQ.png ) Thank you, Mahmoud Al-Qudsi NeoSmart Technologies ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
