On Tue, Jul 07, 2020 at 05:55:32PM +0200, Frederic Cambus wrote:
> On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> Date: Tue, 7 Jul 2020 23:46:00 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Tue, 7 Jul 2020 23:13:06 +0200
> > From: Christian Weisgerber
> >
> > Mark Kettenis:
> >
> > > > --- lib/libc/arch/alpha/gen/usertc.c6 Jul 2020 13:33:05 -
> > > > 1.1
> > > > +++
> The /sys/arch/powerpc/include/timetc.h in your diff never gets used,
> because there is no #include . On macppc,
I am fixing this issue for all the architectures, just being careful
by doing builds first.
> Date: Tue, 7 Jul 2020 23:13:06 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > > --- lib/libc/arch/alpha/gen/usertc.c 6 Jul 2020 13:33:05 -
> > > 1.1
> > > +++ lib/libc/arch/alpha/gen/usertc.c 7 Jul 2020 20:40:37 -
>
> > > +int
> > >
Mark Kettenis:
> > --- lib/libc/arch/alpha/gen/usertc.c6 Jul 2020 13:33:05 -
> > 1.1
> > +++ lib/libc/arch/alpha/gen/usertc.c7 Jul 2020 20:40:37 -
> > +int
> > +tc_get_timecount(struct timekeep *tk, u_int *tc)
>
> Need to make this function static to avoid
Hi George,
On Thu, 25 Jun 2020 23:22:36 -0400
George Koehler wrote:
> On Mon, 22 Jun 2020 19:12:22 +0300
> Paul Irofti wrote:
>
> > New iteration:
> >
> > - ps_timekeep should not coredump, pointed by deraadt@
> > - set ps_timekeep to 0 before user uvm_map for randomization
> > - map
> Date: Tue, 7 Jul 2020 22:49:31 +0200
> From: Christian Weisgerber
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Userland gettime support for alpha.
>
> Alas, completely untested since I don't have access to that arch.
>
> Index:
Userland gettime support for alpha.
Alas, completely untested since I don't have access to that arch.
Index: lib/libc/arch/alpha/gen/usertc.c
===
RCS file: /cvs/src/lib/libc/arch/alpha/gen/usertc.c,v
retrieving revision 1.1
diff -u
As you get older, you gradually get cataracts -which makes your lenses go
yellow. This has the effect of reducing the contrast you experience
with blue. Blue against back is very problematic, while blue is generally
not great anyway.
Eventually, you need an operation to replace your lenses
On 7.7.2020. 10:51, David Gwynne wrote:
> unfortunately em(4) covers a lot of chips of different vintages, so if
> anyone has a super old one they can try this diff on with kstat enabled
> in their kernel config, that would be appreciated.
Hi,
don't know if 82576 is old or super old but here
Mark Kettenis wrote:
> Unless there is an overwhelming majority of users/developers who thing
> the colors should indeed be changed. If there is a significant
> minority that thinks the current colormap severely impacts the
> usability of the framebuffer console, then maybe an interface to
>
> Date: Tue, 7 Jul 2020 17:55:32 +0200
> From: Frederic Cambus
>
> On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has
On 2020/07/07 15:16, Frederic Cambus wrote:
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from the original rasops
wrote:
> Related, I looked through the xterm code to see how hard it would
> be to use some of it directly in the wscons system for accurate
> emulation, and it looked pretty challenging to me. Fixing problems
> piecemeal is probably easier than trying to reuse code.
It was obvious 25-30 years
I have also noticed that comments are hard to read in color-vim
because of the dark blue on black; increasing the intensity would
be a trivial improvement.
I have thought about testing a bold attribute implementation by
way of shift-and-overlay of the font bitmap so all the colors could
be full
> One can test in frame buffer consoles by doing:
>
> export TERM=wsvt25
>
> And run either vim or colorls -G.
Why not set it to wyse30?
Come on. We chose a default. If you change it to some arbitrary value,
then you get to reap the upsides and downsides. Our emulation is *NOT*
'NetBSD
On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > Hi tech@,
> >
> > The recent spike of interest around framebuffer consoles has prompted
> > me to revisit a proposal I sent back in early 2017 [1].
> >
> >
pppac(4) related `ifnet' has `IFXF_CLONED' set. I guess this was done
because we don't collect entropy from pseudo interfaces:
cut begin
void
if_input_process(struct ifnet *ifp, struct mbuf_list *ml)
{
struct mbuf *m;
if (ml_empty(ml))
return;
Hi tech@,
Not so long ago I've ported UHD driver to support Ettus USRP devices which uses
libusb and asynchronous USB3 data transfers.
Is USB3 async. data stack implemented or planned to have some devices like USRP
working?
Martin
> From: "Theo de Raadt"
> Date: Tue, 07 Jul 2020 08:49:41 -0600
>
> Jonathan Gray wrote:
>
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> > > me to revisit a proposal I
Jonathan Gray wrote:
> On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > Hi tech@,
> >
> > The recent spike of interest around framebuffer consoles has prompted
> > me to revisit a proposal I sent back in early 2017 [1].
> >
> > Aesthetics considerations aside, kettenis@
> Date: Tue, 7 Jul 2020 15:16:33 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from
On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from
Hi tech@,
The recent spike of interest around framebuffer consoles has prompted
me to revisit a proposal I sent back in early 2017 [1].
Aesthetics considerations aside, kettenis@ raised the concern that colors
from the original rasops palette carefully matched what OpenFirmware
uses for the
"unfortunately em(4) covers a lot of chips of different vintages, so if
anyone has a super old one they can try this diff on with kstat enabled
in their kernel config, that would be appreciated."
I have a T2000 - is that old enough?
this is a first pass at converting the stats gathering in em(4) to
kstat instead of a disabled printf.
there are some semantic differences. the most obvious is that hardware
counters are not fed into the stacks counters on struct ifnet. i also
don't collect ring based counters (yet).
they look
Hi there,
>From ching Huang
This patch is against to http://bxr.su/OpenBSD/sys/dev/pci/arc.c
1. Adjust some code to meet coding style and have more readability.
2. Add new code for ARC-1203, 1200, 1201 series, they are belong to
ARC_HBA_TYPE_B.
3. Add new code for ARC-1884, it belongs to
On Tue, Jul 07, 2020 at 12:18:20PM +1000, David Gwynne wrote:
> you might want to put the memset after the check to see if the malloc
> failed...
>
Oh, wow... *goes to stand in the corner of shame*
28 matches
Mail list logo
