Re: svn commit: r214817 - head/sys/teken
on 05/11/2010 03:21 Alexander Best said the following: On Fri Nov 5 10, Ed Schouten wrote: Author: ed Date: Fri Nov 5 00:56:21 2010 New Revision: 214817 URL: http://svn.freebsd.org/changeset/base/214817 Log: Partially implement the mysterious cons25 \e[x escape sequence. It seems the terminfo library on some systems (OS X, Linux) may emit the sequence \e[x to reset to default attributes. Apart from using the zero-command, this escape sequence allows many more operations, such as setting ANSI colors. I don't see this used anywhere, so this should be sufficient for now. This deficiency was spotted by the Debian GNU/kFreeBSD. They have their own patch, which is slightly flawed in my opinion. I don't know why they never reported this issue to us. maybe, because nearly all PRs (most of them including patches) they have submitted via GNATS in the past remain unnoticed and thus they've gotten tired of reporting issues and submitting patches if nobody seems to care? ;) Pity that they haven't discovered the mailing lists. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri, Nov 05, 2010 at 01:21:03AM +, Alexander Best wrote: maybe, because nearly all PRs (most of them including patches) they have submitted via GNATS in the past remain unnoticed and thus they've gotten tired of reporting issues and submitting patches if nobody seems to care? ;) We actually do better these days w/rt userland bugs (and some src bugs) than we were a few years ago. I'm always looking for suggestions on how we can get more committers interested in PRs (especially those with patches). mcl ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri, Nov 5, 2010 at 12:25 AM, Mark Linimon lini...@lonesome.com wrote: On Fri, Nov 05, 2010 at 01:21:03AM +, Alexander Best wrote: maybe, because nearly all PRs (most of them including patches) they have submitted via GNATS in the past remain unnoticed and thus they've gotten tired of reporting issues and submitting patches if nobody seems to care? ;) We actually do better these days w/rt userland bugs (and some src bugs) than we were a few years ago. I'm always looking for suggestions on how we can get more committers interested in PRs (especially those with patches). [As is probably well known already among FreeBSD developers] it's better for junior committers (and otherwise newbie committers) to get into the whole userland commit arena. Most of what I see in committer status seems to evolve from userland (optional) to kernel due to the sexiness of kernel work vs userland work. -Garrett ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri Nov 5 10, Mark Linimon wrote: On Fri, Nov 05, 2010 at 01:21:03AM +, Alexander Best wrote: maybe, because nearly all PRs (most of them including patches) they have submitted via GNATS in the past remain unnoticed and thus they've gotten tired of reporting issues and submitting patches if nobody seems to care? ;) We actually do better these days w/rt userland bugs (and some src bugs) than we were a few years ago. I'm always looking for suggestions on how we can get more committers interested in PRs (especially those with patches). unfortunately this might come too late. in 2006 and 2007 apple e.g. submitted quite some patches and tried contributing some work back to the freebsd project. since most of their PR didn't trigger any attention at all, they seem to have completely stopped sending in patches. even if a higher response rate in connection with GNATS can be achieved, these parties (GNU/kFreeBSD, apple, ...) and their manpower are probably lost forever for the freebsd project. since their patches didn't trigger any interest, it is very likely that they have no intentions anymore to contribute any work back: reasonably. expecially in the apple case that's a huge loss. personally i think any contributions by such companies like apple need to have high priority. maybe having a single committer who will interact with apple or other major companies might even be a good idea. this doesn't mean that user contributions aren't as valuable as contributions by companies, but the fact that certain companies have quite a massive manpower, the impact of ignoring their patches is far more severe. if a company wished to have their work pushed back into the freebsd tree this seems to be quite a complex process. maybe 2 or 3 years ago nvidia requested some VM changes for their closed source driver to work on freebsd amd64. they decided to skip the PR databse and directly interacted with developers (i think mostly alc@). so that kinda prooves that the PR databse is not suited very well to get patches committed to freebsd; instead contacting with developers directly seems to be far more successful. but again (as mark pointed out many times) freebsd doesn't have a culture of bug busting. cheers. alex mcl -- a13x ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
Mark Linimon wrote: I'm always looking for suggestions on how we can get more committers interested in PRs (especially those with patches). For PRs with patches that apply to code with a listed MAINTAINER, that maintainer should have to address the PR within 3 days or their own commits should get blocked until they do. Maintainers will then either handle PRs, or stop listing themselves as maintainers, which would open their code up to other committers to commit without maintainer review. It's a win either way, IMO, as far as handling PRs goes. -- Skip ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri Nov 5 10, Skip Ford wrote: Mark Linimon wrote: I'm always looking for suggestions on how we can get more committers interested in PRs (especially those with patches). For PRs with patches that apply to code with a listed MAINTAINER, that maintainer should have to address the PR within 3 days or their own commits should get blocked until they do. Maintainers will then either handle PRs, or stop listing themselves as maintainers, which would open their code up to other committers to commit without maintainer review. It's a win either way, IMO, as far as handling PRs goes. *lol* that would be like polititians agreeing to have their salaries cut in half: NOT GOING TO HAPPEN! -- Skip -- a13x ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri, Nov 05, 2010 at 12:56:21AM +, Ed Schouten wrote: Author: ed Date: Fri Nov 5 00:56:21 2010 New Revision: 214817 URL: http://svn.freebsd.org/changeset/base/214817 Log: Partially implement the mysterious cons25 \e[x escape sequence. It seems the terminfo library on some systems (OS X, Linux) may emit the sequence \e[x to reset to default attributes. Apart from using the zero-command, this escape sequence allows many more operations, such as setting ANSI colors. I don't see this used anywhere, so this should be sufficient for now. This deficiency was spotted by the Debian GNU/kFreeBSD. They have their own patch, which is slightly flawed in my opinion. I don't know why they never reported this issue to us. I'm not sure what happened with this specific patch, but as a general plan they wish to push patches upstream, although it seems we've rejected several of their diffs so far. The full set of their patches are in their svn repository at http://svn.debian.org/wsvn/glibc-bsd/trunk/kfreebsd-8/debian/patches/ and are divided into three categories - changes that are already in our tree now but were not in 8.1, patches they intend to send our way, and patches that are not appropriate for FreeBSD or that we've rejected. I'll see if I can find one of the GNU/kFreeBSD people willing to write up a short summary for each of the patches they apply (and take the thread to freebsd-hackers, if so). -Ed ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri, 5 Nov 2010, Ed Schouten wrote: Log: Partially implement the mysterious cons25 \e[x escape sequence. CSI x is not mysterious. It is from pccons in 386BSD (probably from Net/2, since pccons is also in 4.4BSD). I think it came from pc3 originally. It is still in pccons in NetBSD, at least in 2005. NetBSD pccons only supports CSI [0-3];*x, even in 2005. I added CSI [5-7];*x (set reverse video colors) to pccons in FreeBSD-1. syscons supported all these until recently. Syscons also had the aliases CSI =F/G/H/I, where F/G set normal video colors and H/I set reverse video colors. Now it only has F/G, and has lost its support for setting reverse video colors. I use CSI x in ~/.profile since it was more portable that CSI =F/G/H/I. This broke when I downgraded to -current, so I now use the partial workaround of setting reverse video colors in $TERMCAP: %%% case $TERM in cons25) # Broken in -current: printf '\033[x\033[2;6x\033[1;0x\033[6;7x\033[5;4x' # CSI 0x reset to defaults # CSI 2;6x set ansi foreground cyan #default to ansi background black # CSI 6;7x set ansi reverse foreground white # CSI 5;4x set ansi reverse background blue # Part that still works in -current: printf '\033[=3F\033[=0G' # CSI =3Fset ansi foreground cyan (not different color numbers) # CSI =0Gset ansi background black ;; linux) # I don't remember what this does. Probably less. printf '\033[36;40m\033[1;4]\033[8]' ;; esac case $TERM in cons25) # Workaround for -current brokenness: set colors in termcap, and use better # colors too. This loses mainly the simple restore of defaults by CSI m, # and by expanding the size of the escape sequences. TERMCAP=$TERM:md=\E[1;37m:so=\E[37;44m:se=\E[39;49m:us=\E[1;33;44m:ue=\E[22;39;49m:tc=$TERM: ;; esac %%% The reasons for this fiddling like this with colors are: (1) Reverse video that just reverses the colors tends to give a horrible combination of colors, since the best choices for foreground/background tend to be the worst choices when they are reversed. Thus reverse video should normally be configured to not just reverse the colors, and there should be a way to control this. The CSI [6-7]*x sequences and the CSI =*H/I provided a good way to do this. (2) The colors selected for reverse video should not be undone by other color selections or by almost any escape sequence. the CSI x sequences and CSI =F/G/H/I sequences work right for this. They are not affected by the ANSI color escapes. Of course, an ANSI color escape will change colors set by CSI x, but then on the next CSI m to normal or reverse (etc.) mode, the colors selected by CSI x will be restored. Only a hard terminal reset should lose the settings of CSI x. Hardware terminals are now rare, but ESC c is considered to be a hard reset and does undo CSI x. You have to be careful not to use it. cons25 may also have a soft reset but I don't remember what it is. IIRC, ESC c is from vt100, and vt220 or vt320 had escape sequences for several levels of softer resets, some involving keeping color settings and others not. Termcaps for vt100 mostly don't use ESC c since it really is a hard reset so it resets too much for most purposes. (3) The ANSI color sequences (put in TERMCAP as above) don't work so well for this. First you have to put them in TERMCAP and propagate this to many machines, instead of just writing a single setup sequence on the machine emulating a terminal. Then they have to be written on ever change to/from reverse video/standout/underline. I've noticed a couple of bugs involving the normal mode not being restored. Simpler CSI m sequences tend to restore the normal mode (if there is one) more reliably. (4) To be complete, there would be a separate reverse color pair for every normal color pair (256 combinations even for only 8 colors), but configuring this would be too painful, and fixing 1 normal color pair and its corresponding reverse color pair works OK in practice. Note that normal reverse video gives a different reverse pair for every normal pair, and this feature is lost by fixing the reverse pair. (5) To be complete, standout, underline and blinking (all 2**N combinations of these) would be handled similarly, with a CSI x sequence to select the default colors used in all these modes. x86 displays have various deficiencies in being able to display all combinations of attributes simultaneously or at all, and syscons has too many hard-coded color choices for combinations that are not directly representable. But configuring the general case would be too painful. In the above, my TERMCAP color choices don't worry about this, so standout followed by underline would give the colors for just one of standout or underline depending on which order
svn commit: r214817 - head/sys/teken
Author: ed
Date: Fri Nov 5 00:56:21 2010
New Revision: 214817
URL: http://svn.freebsd.org/changeset/base/214817
Log:
Partially implement the mysterious cons25 \e[x escape sequence.
It seems the terminfo library on some systems (OS X, Linux) may emit the
sequence \e[x to reset to default attributes. Apart from using the
zero-command, this escape sequence allows many more operations, such as
setting ANSI colors. I don't see this used anywhere, so this should be
sufficient for now.
This deficiency was spotted by the Debian GNU/kFreeBSD. They have their
own patch, which is slightly flawed in my opinion. I don't know why they
never reported this issue to us.
MFC after:1 week
Modified:
head/sys/teken/sequences
head/sys/teken/teken_subr_compat.h
Modified: head/sys/teken/sequences
==
--- head/sys/teken/sequencesFri Nov 5 00:31:09 2010(r214816)
+++ head/sys/teken/sequencesFri Nov 5 00:56:21 2010(r214817)
@@ -106,6 +106,7 @@ C25ADFG Cons25 set adapter foreground ^
C25BLPDCons25 set bell pitch duration ^[ [ = Br r
C25CURSCons25 set cursor type ^[ [ = Sr
C25MODECons25 set terminal mode^[ [ = Tr
+C25SGR Cons25 set graphic rendition^[ [ x r r
C25VTSWCons25 switch virtual terminal ^[ [ z r
# VT52 compatibility
Modified: head/sys/teken/teken_subr_compat.h
==
--- head/sys/teken/teken_subr_compat.h Fri Nov 5 00:31:09 2010
(r214816)
+++ head/sys/teken/teken_subr_compat.h Fri Nov 5 00:56:21 2010
(r214817)
@@ -88,6 +88,20 @@ teken_subr_cons25_set_bell_pitch_duratio
}
static void
+teken_subr_cons25_set_graphic_rendition(teken_t *t, unsigned int cmd,
+unsigned int param __unused)
+{
+
+ switch (cmd) {
+ case 0: /* Reset. */
+ t-t_curattr = t-t_defattr;
+ break;
+ default:
+ teken_printf(unsupported attribute %u\n, cmd);
+ }
+}
+
+static void
teken_subr_cons25_set_terminal_mode(teken_t *t, unsigned int mode)
{
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r214817 - head/sys/teken
On Fri Nov 5 10, Ed Schouten wrote:
Author: ed
Date: Fri Nov 5 00:56:21 2010
New Revision: 214817
URL: http://svn.freebsd.org/changeset/base/214817
Log:
Partially implement the mysterious cons25 \e[x escape sequence.
It seems the terminfo library on some systems (OS X, Linux) may emit the
sequence \e[x to reset to default attributes. Apart from using the
zero-command, this escape sequence allows many more operations, such as
setting ANSI colors. I don't see this used anywhere, so this should be
sufficient for now.
This deficiency was spotted by the Debian GNU/kFreeBSD. They have their
own patch, which is slightly flawed in my opinion. I don't know why they
never reported this issue to us.
maybe, because nearly all PRs (most of them including patches) they have
submitted via GNATS in the past remain unnoticed and thus they've gotten tired
of reporting issues and submitting patches if nobody seems to care? ;)
cheers.
alex
MFC after: 1 week
Modified:
head/sys/teken/sequences
head/sys/teken/teken_subr_compat.h
Modified: head/sys/teken/sequences
==
--- head/sys/teken/sequences Fri Nov 5 00:31:09 2010(r214816)
+++ head/sys/teken/sequences Fri Nov 5 00:56:21 2010(r214817)
@@ -106,6 +106,7 @@ C25ADFG Cons25 set adapter foreground ^
C25BLPD Cons25 set bell pitch duration ^[ [ = Br r
C25CURS Cons25 set cursor type ^[ [ = Sr
C25MODE Cons25 set terminal mode^[ [ = Tr
+C25SGR Cons25 set graphic rendition^[ [ x r r
C25VTSW Cons25 switch virtual terminal ^[ [ z r
# VT52 compatibility
Modified: head/sys/teken/teken_subr_compat.h
==
--- head/sys/teken/teken_subr_compat.hFri Nov 5 00:31:09 2010
(r214816)
+++ head/sys/teken/teken_subr_compat.hFri Nov 5 00:56:21 2010
(r214817)
@@ -88,6 +88,20 @@ teken_subr_cons25_set_bell_pitch_duratio
}
static void
+teken_subr_cons25_set_graphic_rendition(teken_t *t, unsigned int cmd,
+unsigned int param __unused)
+{
+
+ switch (cmd) {
+ case 0: /* Reset. */
+ t-t_curattr = t-t_defattr;
+ break;
+ default:
+ teken_printf(unsupported attribute %u\n, cmd);
+ }
+}
+
+static void
teken_subr_cons25_set_terminal_mode(teken_t *t, unsigned int mode)
{
--
a13x
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
