Pointer acceleration in X
When X is configured to enable use of the numeric keypad to simulate a mouse, using Pointer_EnableKeys in Xmodmap, the pointer acceleration doesn't work as expected. Specifically, when a directional key is held down, the pointer accelerates up to a point, then stops, and begins accelerating again, and stops, repeatedly. Presumably a counter somewhere is wrapping round to zero instead of reaching it's maximum value and stopping. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 02:47:10PM -0500, Ted Unangst wrote: Tati Chevron wrote: On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote: >Your emails only contain opinions. "Questions, comments, suggestions and any kind of help would also be welcome". Sorry if I mis-understood the purpose of a mailing list. Your suggestions aren't helpful. Quoting the mailling list rules isn't making them more helpful. I was quoting Ulf's original post! -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 06:29:23PM +0100, Stefan Sperling wrote: On Wed, Dec 16, 2015 at 05:10:45PM +, Tati Chevron wrote: why does it have to be integrated into the same mouse driver that everybody else uses? Since you seem to care about this topic enough to actually contend with what Ulf has been working on for months, let's phrase it this way: Ulf's mails have diffs attached, and yours don't. Easy choice. I don't see the connection. I don't agree with the idea, nor see any real-world use or benefit to this change. Response of any kind on the list has been very limited too. Even Ulf has commented that maybe people are happy with things the way they are. What diffs would you expect to see from anyone who wanted no change? I've had several input layer diffs in my own personal tree for over four years that were rejected by Miod as not having a general use case. No problem. I maintain them, because I use them. If you and Ulf have a use for these changes, but nobody else is interested enough to even test and comment, why are you so worried? As much as we'd like to keep things stable, we need to make progress, too. But it has to be progress in a useful direction, surely? And why can't this all be done in a separate driver that doesn't touch wsmouse? And of course the community is not going to accept diffs (from anyone) which cause major regressions. So I don't see why you're so worried. To me, the extra and unnecessary code running on every machine that just has a PS/2 mouse, is a regression. If we did this with everything, we'd be Linux. The good thing about OpenBSD for me is that it supports a few things very well, rather than trying to support every possible use case regardless of it's state of readiness or if it has a real value. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 12:59:00PM -0500, Ted Unangst wrote: Tati Chevron wrote: But I don't see that touch-based devices are ever going to become the most common devices to run OpenBSD, that's not realistic. Even ignoring servers and headless devices, and only counting devices that are used interactively in some way, I just don't see tablet devices becoming the most widely used. Progress is not made by people saying they don't like progress. I'm all for progress, but I don't see any being made, here, or in the world of touch devices in general. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote: Your emails only contain opinions. "Questions, comments, suggestions and any kind of help would also be welcome". Sorry if I mis-understood the purpose of a mailing list. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: Linker changes between 5.7 and 5.8
On Sat, Dec 05, 2015 at 07:33:11AM +0100, Stefan Kempf wrote: Tati Chevron wrote: This assembled and linked without problems on 5.7-release, but now when I try it on 5.8-release, I get an error: $ as -o charset.o charset.S $ ld -Bstatic charset.o ld: charset.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC charset.o: could not read symbols: Bad value Try it with ld -Bstatic -nopie charset.o Ahhh, I was using -no-pie and wondering why it didn't work :-). Great, so compiling with -nopie produces a working executable, excellent, thanks. But I thought that amd64 was already using static pie by default in 5.7? The release notes at http://www.openbsd.org/57.html suggest this: All architectures have been transitioned to static PIE -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Linker changes between 5.7 and 5.8
This assembled and linked without problems on 5.7-release, but now when I try it on 5.8-release, I get an error: $ as -o charset.o charset.S $ ld -Bstatic charset.o ld: charset.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC charset.o: could not read symbols: Bad value What's changed? charset.S is fairly trivial: .section ".note", "a" .p2align 2 .long 0x08 .long 0x04 .long 0x01 .ascii "OpenBSD\0" .long 0x00 .p2align 2 .section .data bytestore: .quad 0x20 welcome: .ascii "Characterset generator by Tati Chevron, 27/4/2015." .byte 0x0A newline: .quad 0x0A .section .text .globl _start _start: mov $welcome, %rsi mov $1, %rdi mov $4, %rax mov $53, %rdx syscall _loop: push bytestore pop %rax cmp $0xFF, %rax jz _exit cmp $0x80, %rax jnz _skip call _nl push bytestore pop %rax _skip: inc %rax mov %rax, bytestore mov $4, %rax mov $1, %rdi mov $bytestore, %rsi mov $1, %rdx syscall jmp _loop _exit: call _nl mov $1, %rdi mov $1, %rax syscall _nl: mov $4, %rax mov $1, %rdi mov $newline, %rsi mov $1, %rdx syscall ret -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: Linker changes between 5.7 and 5.8
ld ignores the -fno-pie option and produces the same error. Presumably it's because I'm trying to build a static executable. I've tried passing every option I can think of to ld, but I can't work it out. The output from the assembler is fine, can be linked on a machine running 5.7, and the resulting binary executes on a 5.8 box. I'm not sure where else to look... On Fri, Dec 04, 2015 at 03:55:09PM -0700, Theo de Raadt wrote: Most architectures went to 'static PIE' by default in 5.8. You will probably need something like -fno-pie. The entire exercise of writing asm which bootstraps without the c runtime means you are very much on your own. This assembled and linked without problems on 5.7-release, but now when I try it on 5.8-release, I get an error: $ as -o charset.o charset.S $ ld -Bstatic charset.o ld: charset.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC charset.o: could not read symbols: Bad value What's changed? charset.S is fairly trivial: .section ".note", "a" .p2align 2 .long 0x08 .long 0x04 .long 0x01 .ascii "OpenBSD\0" .long 0x00 .p2align 2 .section .data bytestore: .quad 0x20 welcome: .ascii "Characterset generator by Tati Chevron, 27/4/2015." .byte 0x0A newline: .quad 0x0A .section .text .globl _start _start: mov $welcome, %rsi mov $1, %rdi mov $4, %rax mov $53, %rdx syscall _loop: push bytestore pop %rax cmp $0xFF, %rax jz _exit cmp $0x80, %rax jnz _skip call _nl push bytestore pop %rax _skip: inc %rax mov %rax, bytestore mov $4, %rax mov $1, %rdi mov $bytestore, %rsi mov $1, %rdx syscall jmp _loop _exit: call _nl mov $1, %rdi mov $1, %rax syscall _nl: mov $4, %rax mov $1, %rdi mov $newline, %rsi mov $1, %rdx syscall ret -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Building flavors with dpb
I'm trying to build the no_ada flavour of gcc 4.9 using dpb on a machine running 5.8-release, and it fails: # export FLAVOR=no_ada # dpb -D BUILD_USER=ports -D CDROM_ONLY -D FTP_ONLY -F 0 -L /portswork/logs -l /portswork/locks lang/gcc/4.9 Fatal: Unknown flavor(s) no_ada (in test/a) (No flavors for this port). (in test/a) *** Error 1 in / (/usr/ports/infrastructure/mk/bsd.port.mk:3567 '.BEGIN': @exit 1) dpb: Can't obtain vital information from the ports tree Usage: dpb [-aceimqrRsuUvx] [-A arch] [-B chroot] [-C plist] [-f m] [-F m] [-I pathlist] [-J p] [-j n] [-p parallel] [-P pathlist] [-h hosts] [-L logdir] [-l lockdir] [-b log] [-M threshold] [-X pathlist] [pathlist ...] Infact, trying to build other flavoured ports fails in a similar way. What am I doing wrong here? -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: Debugging cardbus issues
On Sat, Nov 28, 2015 at 07:18:25PM +0100, Mark Kettenis wrote:
Date: Sat, 28 Nov 2015 17:12:03 +
From: Tati Chevron <chev...@swabsit.com>
cbb0 at pci1 dev 9 function 0 "ENE CB-1410 CardBus" rev 0x01: apic 1 int 22,
CardBus support disabled
cardslot0 at cbb0 slot 0 flags 0
pcmcia0 at cardslot0
The host interface attaches, but my understanding is that the
CardBus support disabled message means that no driver attached to
the connected device. Or am I wrong?
It means that the BIOS didn't configure the cardbus controller
properly, and that OpenBSD didn't succeed in patching things up.
Ah, OK, interesting...
Since your ccb0 attaches to pci1, you should try the ppb diff I mailed
to tech@ earlier today.
This machine is running 5.8-release, so I updated ppb.c to the latest revision
from CVS and applied your attached patch.
The kernel compiles and boots successfully, but the dmesg and lspci output
remains exactly the same.
Does this patch rely on other changed code between 5.8-release and 5.8-current?
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.64
diff -u -p -r1.64 ppb.c
--- ppb.c 19 Oct 2015 19:24:54 - 1.64
+++ ppb.c 28 Nov 2015 12:44:06 -
@@ -66,6 +66,7 @@ struct ppb_softc {
pcitag_t sc_tag;/* ...and tag. */
pci_intr_handle_t sc_ih[4];
void *sc_intrhand;
+ struct extent *sc_busex;
struct extent *sc_ioex;
struct extent *sc_memex;
struct extent *sc_pmemex;
@@ -106,6 +107,8 @@ struct cfdriver ppb_cd = {
NULL, "ppb", DV_DULL
};
+void ppb_alloc_busrange(struct ppb_softc *, struct pci_attach_args *,
+ pcireg_t *);
voidppb_alloc_resources(struct ppb_softc *, struct pci_attach_args *);
int ppb_intr(void *);
voidppb_hotplug_insert(void *);
@@ -151,6 +154,7 @@ ppbattach(struct device *parent, struct
pci_intr_handle_t ih;
pcireg_t busdata, reg, blr;
char *name;
+ int sec, sub;
int pin;
sc->sc_pc = pc;
@@ -158,6 +162,16 @@ ppbattach(struct device *parent, struct
busdata = pci_conf_read(pc, pa->pa_tag, PPB_REG_BUSINFO);
+ /*
+* When the bus number isn't configured, try to allocate one
+* ourselves.
+*/
+ if (busdata == 0 && pa->pa_busex)
+ ppb_alloc_busrange(sc, pa, );
+
+ /*
+* When the bus number still isn't set correctly, give up.
+*/
if (PPB_BUSINFO_SECONDARY(busdata) == 0) {
printf(": not configured by system firmware\n");
return;
@@ -175,6 +189,19 @@ ppbattach(struct device *parent, struct
pa->pa_bus, PPB_BUSINFO_PRIMARY(busdata));
#endif
+ sec = PPB_BUSINFO_SECONDARY(busdata);
+ sub = PPB_BUSINFO_SUBORDINATE(busdata);
+ if (sub > sec) {
+ name = malloc(PPB_EXNAMLEN, M_DEVBUF, M_NOWAIT);
+ if (name) {
+ snprintf(name, PPB_EXNAMLEN, "%s pcibus",
sc->sc_dev.dv_xname);
+ sc->sc_busex = extent_create(name, 0, 0xff,
+ M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
+ extent_free(sc->sc_busex, sec + 1,
+ sub - sec, EX_NOWAIT);
+ }
+ }
+
/* Check for PCI Express capabilities and setup hotplug support. */
if (pci_get_capability(pc, pa->pa_tag, PCI_CAP_PCIEXPRESS,
>sc_cap_off, ) && (reg & PCI_PCIE_XCAP_SI)) {
@@ -313,6 +340,7 @@ ppbattach(struct device *parent, struct
pba.pba_dmat = pa->pa_dmat;
pba.pba_pc = pc;
pba.pba_flags = pa->pa_flags & ~PCI_FLAGS_MRM_OKAY;
+ pba.pba_busex = sc->sc_busex;
pba.pba_ioex = sc->sc_ioex;
pba.pba_memex = sc->sc_memex;
pba.pba_pmemex = sc->sc_pmemex;
@@ -338,6 +366,12 @@ ppbdetach(struct device *self, int flags
rv = config_detach_children(self, flags);
+ if (sc->sc_busex) {
+ name = sc->sc_busex->ex_name;
+ extent_destroy(sc->sc_busex);
+ free(name, M_DEVBUF, PPB_EXNAMLEN);
+ }
+
if (sc->sc_ioex) {
name = sc->sc_ioex->ex_name;
extent_destroy(sc->sc_ioex);
@@ -485,6 +519,25 @@ ppbactivate(struct device *self, int act
}
void
+ppb_alloc_busrange(struct ppb_softc *sc, struct pci_attach_args *pa,
+pcireg_t *busdata)
+{
+ pci_chipset_tag_t pc = sc->sc_pc;
+ u_long busnum, busrange;
+
+ for (busrange = 8; busrange > 0; busrange >>= 1) {
+ if (extent_alloc(pa->pa_busex, busrange, 1, 0, 0,
+ EX_NOWAIT, ))
+ continue;
+ *busdata |= pa->pa_bus;
+
Debugging cardbus issues
non-parity PC2-4200CL4 SO-DIMM spdmem1 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-3200CL5 SO-DIMM usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pms0: Synaptics touchpad, firmware 6.2 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (3c339ffd90931f05.a) swap on wd0b dump on wd0b 06:09.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01) Subsystem: Acer Incorporated [ALI] Device 006a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 Capabilities: [a0] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Unknown cardbus ethernet controller
"Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pms0: Synaptics touchpad, firmware 6.2
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (3c339ffd90931f05.a) swap on wd0b dump on wd0b
06:09.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)
Subsystem: Acer Incorporated [ALI] Device 006a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Capabilities: [a0] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com
Re: pledge for tetris
On Tue, Nov 17, 2015 at 12:21:32AM -0500, Michael McConville wrote: Ted Unangst wrote: Theo Buehler wrote: > drop the score file support No way! this is critical functionality. :) Seconded. :P I disagree - the obvious solution is to move tetris to ports for anyone who needs score file support, and for Ted to write a new cut down alternative version to go in base. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: [PATCH] add F13-F24 and colour support to console terminfo
On Mon, Nov 09, 2015 at 08:23:08AM +, Nicholas Marriott wrote: On Sun, Nov 08, 2015 at 09:01:52PM +, Tati Chevron wrote: Is there any reason why the OpenBSD installer still defaults to a terminal type of vt-220 for the VGA framebuffer console, and doesn't even suggest pccon as an alternative? In the installer itself? vt220 works fine and reliably and - importantly - is small and fits on the ramdisks. Who needs to press F13 in the installer? Agreed, I didn't mean the installer itself, that does work fine with vt220. If you mean in /etc/ttys, this has been discussed before and mostly the reason it has stayed is that terminfo entries propagate very slowly and vt220 is available everywhere, no matter if the user ssh to some ancient OS. It's easy to change anyway. Ah, then this is a documentation issue - I always assumed that the terminal type specified in the installer was propogated to /etc/ttys during the install, and used as a default for the console. It is indeed easy to change, but the existance of pccon isn't exactly widely documented. To be honest, I knew about it, but seeing that it was broken and not used by default in the installer, nor on the console after installation, I assumed that it was abandoned and unmaintained. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: [PATCH] add F13-F24 and colour support to console terminfo
Hi, On Sun, Nov 08, 2015 at 08:18:55PM +, Nicholas Marriott wrote: Hi I think it should be Shift-F1 etc, but since this is a general problem with the xterm entry not just on OpenBSD, I suggest you discuss it with upstream. The terminfo database is maintained as part of ncurses. OK, I'll look into that, and maintain a local patch here for X for the time being. Is there any reason why the OpenBSD installer still defaults to a terminal type of vt-220 for the VGA framebuffer console, and doesn't even suggest pccon as an alternative? -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: [PATCH] add F13-F24 and colour support to console terminfo
On Sun, Nov 08, 2015 at 02:09:03PM +, Nicholas Marriott wrote:
If this is different from pccon*, you should fix those or add a variant
rather than adding completely new entries.
OK. The attached diff does the following:
* Add F13-F24 to pccon.
These were previously undefined.
* Change the sgr definition to match the vt220 entry.
This makes the, 'intense', colours work, giving us 16 instead of 8.
* Define the bold sequence.
Otherwise, E.G. 'echo foo | less', the ~ in column 0 are displayed as
reverse video instead of bold, (as they do in xterm).
* Add a new entry, 'pcconX', that adds F13-F24 to the standrd xterm entry
--- termtypes.master.1.55.dist Sun Nov 8 15:20:37 2015
+++ termtypes.masterSun Nov 8 15:42:04 2015
@@ -2184,13 +2184,16 @@
kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
kf9=\E[20~, khome=\E[7~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~,
krfr=^R,
+ kf13=\E[25~, kf14=\E[26~, kf15=\E[28~, kf16=\E[29~,
+ kf17=\E[31~, kf18=\E[32~, kf19=\E[33~, kf20=\E[34~,
+ kf21=\E[35~, kf22=\E[36~, kf23=\E[37~, kf24=\E[38~,
pccon+sgr+acs0|sgr and simple ASCII pseudographics for OpenBSD PC console,
acsc=+>\,<-\^.v0#`+a\:f\\h#i#j+k+l+m+n+o~p-q-r-s_t+u+v+w+x|y#z#{*|!}#~o,
sgr=\E[0%?%p1%p3%|%t;7%;m, sgr0=\E[m,
pccon+sgr+acs|sgr and default ASCII pseudographics for OpenBSD PC console,
acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
enacs=\E)0$<5>, rmacs=\E(B$<5>,
- sgr=\E[0%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;$<5>,
+
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;$<2>,
sgr0=\E[m\E(B$<5>, smacs=\E(0$<5>,
pccon+colors|ANSI colors for OpenBSD PC console,
bce,
@@ -2199,7 +2202,7 @@
pccon+base|base capabilities for OpenBSD PC console,
am, km, mc5i, msgr, npc, nxon, xenl, xon,
cols#80, it#8, lines#24,
- bel=^G, clear=\E[H\E[J, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ bel=^G, bold=\E[1m, clear=\E[H\E[J, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch=\E[%p1%dP,
dch1=\E[P, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
@@ -2214,6 +2217,11 @@
use=pccon+base, use=pccon+sgr+acs, use=pccon+keys,
pccon|OpenBSD PC console,
use=pccon-m, use=pccon+colors,
+pcconX|xterm-like entry that fixes behaviour of F13-F24 in X on OpenBSD,
+ kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf20=\E[34~, kf21=\E[42~, kf22=\E[43~,
+ kf23=\E[44~, kf24=\E[45~, khlp=, krdo=, use=xterm,
NetBSD consoles
#
--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com
Re: [PATCH] add F13-F24 and colour support to console terminfo
On Sun, Nov 08, 2015 at 04:50:21PM +, Nicholas Marriott wrote: Can you please send these upstream to Thomas Dickey or bug-ncur...@gnu.org? Done. * Add a new entry, 'pcconX', that adds F13-F24 to the standrd xterm entry Not this though - pccon* is for the console, not for use in xterm. I think you might want xterm-vt220? Hu, no, xterm-vt220 doesn't define F21-F24, and also has an incorrect definition for the, 'home', key. I can make a diff for this, obviously, should I just add it as a variation? Although I don't know why our xterm function keys should be different from stock xterm. Since F13-F24 don't exist on standard PC keyboards, traditionally terminal emulators have mapped shift-F1 to F13, shift-F2 to F14, etc. In recent times, some 122-key terminal keyboards, which are designed to be used with terminal emulators like that, actually send sequences such as Shift-F1 when the physical F13 key is pressed, instead of the, 'real', sequence. If you look in xterm+pcf2, which is the fragment included in the default xterm terminfo entry that we use, you'll see that F13-F24 are indeed defined as Shift-F1 - Shift-F12. Unfortunately, even this doesn't work correctly for us, because F1-F4 don't follow the normal sequence for historical reasons. So, we should do something to make sure that the default terminal emulation used for xterm on a default install, has a sensible configuration for F13-F24. Either support the, 'real', sequences from a 122-key keyboard, or support the shifted F1-F12 keys as F13-F24, or preferably, both. Shall I make a diff to fix this? -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
[PATCH] add F13-F24 and colour support to console terminfo
The terminfo entries used for X and for the console by a default install, are broken for keyboards with function keys beyond F12, and for keyboards with five cursor movement keys instead of the more common four. In addition, the VGA console supports colour, but the terminfo entry used by default does not define the necessary escape sequences. Please find attached a patch against -current which defines three new terminfo entries to fix these problems. --- termtypes.master.1.55.dist Sun Nov 8 11:40:24 2015 +++ termtypes.master.1.55.customSun Nov 8 11:43:06 2015 @@ -291,6 +291,51 @@ # There are no guarantees anywhere. Svaha! # + CUSTOM ENTRIES FOR OPENBSD-5.8 +# +# Three entries to allow the use of F1-F5, F13-F24 and colour on the +# OpenBSD VGA framebuffer console, and the use of F13-F24 with the default +# X config. +# +# In addition, the, 'home', key on a PC-122 keyboard is defined as, 'home', +# on the console, to match the definition in X: +# +# On a standard PC keyboard, there are four cursor keys in an inverted, 'T', +# whereas on a PC-122 keyboard there are five cursor keys: +# +# --- --- Legend +# |^| |^| -- +# --- --- +# --- --- --- --- --- --- ^ - UP +# |<| |V| |>| |<| |H| |>| V - DOWN +# --- --- --- --- --- --- < - LEFT +# --- > - RIGHT +# |V| H - HOME +# --- +# +# PC Keyboard PC-122 Keyboard +# +# The new entries in this file are as follows: +# tati - OpenBSD console with F1-F24, 5-key cursor-key block, and colour. +# tatimono - As above, but without colour support +# tatiX - X11 xterm with F1-F24, (colour and 5-key cursor-key block were +# already supported by the existing xterm entry. + +tatimono|OpenBSD console with F1-F24 without colour support, + kf1=\E[11~, kf2=\E[12~, kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, + kf15=\E[28~, kf16=\E[29~, kf21=\E[35~, kf22=\E[36~, + kf23=\E[37~, kf24=\E[38~, khome=\E[7~, khlp=, krdo=, use=vt220, + +tati|OpenBSD console with F1-F24 and colour, + use=tatimono, use=ecma+color, + +tatiX|vt220-like entry that fixes behaviour of F13-F24 in X on OpenBSD, + kf13=\E[25~, kf14=\E[26~, + kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, + kf19=\E[33~, kf20=\E[34~, kf21=\E[42~, kf22=\E[43~, + kf23=\E[44~, kf24=\E[45~, khlp=, krdo=, use=xterm, + + ANSI, UNIX CONSOLE, AND SPECIAL TYPES # # This section describes terminal classes and brands that are still -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
