git/push died within a subshell, which prevented the
whole program from exiting, and lead to an incorrect
ref update line that confused people.
git/send would eventually error out, but would push
all the data before that happened; this was annoying.
It's not fatal for someone else to push a branch
with objects that we don't have. We should deal
with it gracefully, and act as though it doesn't
exist.
In showlist, call bwindata instead of bwinopen in order to use a
pre-existing fd to write to the data file. This existing fd will
properly honour any address set by a previous write to the addr file.
Specifically, the redraw function sets addr to "," before calling
showlist in order to overwrite the entire contents of the window.
This is implemented by checking first if the uri is
a directory containing the .git/ subdirectory.
If this is the case, we fork git/serve serving the
repository on a pipe.
We weren't giving all objects to the twixt() function, and
it was making bad life choices -- gambling, smoking, drinking,
and packing in too much data.
With more information, it doesn't do the last.
For 64-bit architectures, the a.out header has the HDR_MAGIC flag set
in the magic and is expanded by 8 bytes containing the 64-bit virtual
address of the programs entry point. While Exec.entry contains physical
address for kernel images.
Our sysexec() would always use Exec.entry, even for 64-bit a.out binaries,
which worked because PADDR(entry) == entry for userspace pointers.
This change fixes it, having the kernel use the 64-bit entry point
and document the behaviour in the manpage.
The 9p debug server was broken as it assumed the first
tree file added would have a qid of 0 (it has a qid
of 1 as the root directory is using 0 already).
Instead, just compare File* pointers and get rid of
the table (less code).
When passing 64-bit unsigned addresses as 64-bit signed
file offsets, we have to make sure to not pass negative
offsets (filtered out by kernel and lib9p)!
This is solved by clearing and sign bit in encoding and
63-bit sign extension on decoding.
Make the mem file writable (needed for acid).
The 9p debug server provided a single directory containing
mem and regs files. This patch renames the regs file
(which is in vmx specific text format) to "xregs" and
adds "regs" and "kregs" file which use the same format
as exported by the kernels /proc filesystem.
This allows one to bind the vmx directory over a proc
directory and attach acid to a running system like:
mount -b /srv/vmx /proc/1
acid -k -lkernel 1 /sys/src/9/pc64/9pc64
If we tokenize the register file contents in a static buffer,
we can avoid having to duplicate the register names.
All callers to rpoke() provide constant register arguments
so they also do not need to be duplicated.
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
Now that we have these new functions,
we can also make them return an error
instead of calling sysfatal() like
postmountsrv().
Remove the confusing Srv.srvfd, as it
is only temporarily used and return
it from postsrv() instead.
To use srvrease()/srvaquire() we need to have a way to spawn
new processes to handle the service loop. This functionality
was provided by the internal _forker() function which was
eigther rfork or libthread based implementation depending on
if postmountsrv() or threadpostmountsrv() where called.
For servers who want to use srv() directly, _forker would not
be initialized so srvrelease() could not be used.
To untangle this, we get rid of the global _forker handler
and put the handler in the Srv structure. Which will get
initialized (when nil) to eigther srvforker() or threadsrvforker()
depending on if the thread or non-thread entry points where used.
For symmetry, we provde new threadsrv() and threadpostsrv()
functions which handle the default initialization of Srv.forker.
This also allows a user to provide his own forker function,
maybe to conserve stack space.
To avoid dead code, we put each of these function in their
own object file. Note, this also allows a user to define its
own srvforker() symbol.
this fixes real-time applications.
-n previously specified a rate divisor rather than the rate itself,
which was used for specific applications outside of 9front. instead,
just set the rate directly, more useful and straightforward.
Remove unused fields and factor common fields into a
new PMach struct in port/portdat.h.
The fields machno, splpc and proc are not moved to
PMach as they are part of the known offsets from
assembly (l.s).
Resample is well known for taking a long time to resize an image. This
patch brings an important performance boost (in my test image, time
was reduced from ~2850ms to ~500ms). It does that by extracting FP
multiplication and division out of the innermost loop of
resamplex/resampley.
The results differ slightly from the current implementation: in my
test: ~0.3% of the bytes had a ±2 difference in their value, which I
attribute to rounding errors. I'm personally not concerned with that
deviation, given the performance gains. However, I recommend testing
it just to be sure I didn't overlook anything.
José Miguel Sánchez García
The patch does the following:
1. Adds recognition of executable script (shebang) files.
2. Returns correct MIME type for mbox files (RFC 4155).
3. Returns XML instead of HTML type in some cases.
changeset: 8411:19f6a88ea241
branch: mbp-2011
user: Romano <unobe@cpan.org>
date: Sat Apr 17 14:35:21 2021 -0700
files: sys/src/cmd/upas/fs/imap.c
description:
When an imap fetch fails, it's helpful at times to know the underlying
cause. This provides more details by providing the underlying error
message.
unlike other tools like iconv(1), a crop(1) without arguments or with
ones resulting in a no-op, like `-t 0 0', errors out. other options
like `-i 0' do not error. this breaks assumptions and results in
tedious intermediary steps or hacks like:
foo | {crop -t $1 $2 >[2]/null || cat} > baz.bit
instead, just ignore the check. subsequent code doesn't make
assumptions on that.
/sys/src/cmd/mksyslib uses `{basename $stem .$objtype}^.c to get the
source file name for *.acid files. /sys/lib/acid/thread expects
sched.$objtype.acid. This lets /sys/src/libthread/mkfile generate
that file.
This patch adds dirmodefmt from fcall.h to pretty-print file
permissions, similarly to ls -l. I didn't notice any performance
degradation.
I hope no-one relied on the old behaviour.
i have found one bug. when i put glenda in a position like this
i somehow win, but the glenda can escape from there.
in addition, i have changed the games manpage to include more info about glendy.
We can take advantage of the fact that xinit() allocates
kernel memory from conf.mem[] banks always at the beginning
of a bank, so the separate palloc.mem[] array can be eleminated
as we can calculate the amount of non-kernel memory like:
upages = cm->npage - (PGROUND(cm->klimit - cm->kbase)/BY2PG)
for the number of reserved kernel pages,
we provide the new function: ulong nkpages(Confmem*)
This eleminates the error case of running out of slots in
the array and avoids wasting memory in ports that have simple
memory configurations (compared to pc/pc64).
To reproduce the suicide try running the following in acme:
• 'Edit B <ls lib'
by select and middle clicking in a window that is in your $home.
There is a very high chance acme will commit suicide like this:
<snip>
cpu% broke
echo kill>/proc/333310/ctl # acme
cpu% acid 333310
/proc/333310/text:amd64 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/amd64
acid: lstk()
edittext(nr=0x31,q=0x0,r=0x45aa10)+0x8 /sys/src/cmd/acme/ecmd.c:135
xfidwrite(x=0x461230)+0x28a /sys/src/cmd/acme/xfid.c:479
w=0x0
qid=0x5
fc=0x461390
t=0x1
nr=0x100000031
r=0x45aa10
eval=0x3100000000
a=0x405621
nb=0x500000001
err=0x419310
q0=0x100000000
tq0=0x80
tq1=0x8000000000
buf=0x41e8d800000000
xfidctl(arg=0x461230)+0x35 /sys/src/cmd/acme/xfid.c:52
x=0x461230
launcheramd64(arg=0x461230,f=0x22357e)+0x10 /sys/src/libthread/amd64.c:11
0xfefefefefefefefe ?file?:0
</snap>
The suicide issue is caused by the following chain of events:
• /sys/src/cmd/acme/ecmd.c:/^edittext is called at
/sys/src/cmd/acme/xfid.c:479 passing nil as its first parameter:
<snip>
...
case QWeditout:
r = fullrunewrite(x, &nr);
if(w)
err = edittext(w, w->wrselrange.q1, r, nr);
else
err = edittext(nil, 0, r, nr);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
</snap>
...and /sys/src/cmd/acme/ecmd.c:/^edittext dereferences the
first parameter that is *nil* at the first statement:
<snip>
char*
edittext(Window *w, int q, Rune *r, int nr)
{
File *f;
f = w->body.file;
^^^^^^^^^^^^^^^^^^^^^
This will crash if 'w' is *nil*
switch(editing){
...
</snap>
Moving the the derefernce of 'w' into the case where it is
needed (see above patch) fixes the suicude.
The memory leak is fixed in /sys/src/cmd/acme/ecmd.c:/^filelist. The
current implementation of filelist(...) breaks its contract with its
caller, thereby leading to a memory leak in /sys/src/cmd/acme/ecmd.c:/^B_cmd
and /sys/src/cmd/acme/ecmd.c:/^D_cmd.
The contract /sys/src/cmd/acme/ecmd.c:/^filelist seems to have with
its callers is that in case of success it fills up a 'collection' that
callers can then clear with a call to clearcollection(...).
The fix above honours this contract and thereby removes the leak.
After you apply the patch the following two tests should succeed:
• Execute by select and middle click in a Tag:
'Edit B lib/profile'
• Execute by select and middle click in a Tag:
'Edit B <ls lib'
The former lead to a resource leak that is now fixed.
The latter lead to a suicide that is now fixed by moving the statement
that dereferences the parameter to the location where it is needed,
which is not the path used in the case of 'Edit B <ls'.
Cheers,
Igor
The confstr was shared between readers so seprintconf() could
write concurrently to that buffer which is not safe.
This replaces the shared static confstr[Maxconf] buffer with a
pointer that is initially nil and a buffer that is alloced on
demand.
The new confstr pointer (and buffer) is now only updated while
wlock()ed from the new setconfstr() function.
This is now done by mconfig() / mdelctl() just before releasing
the wlock.
Now, rdconf() will check if confstr has been initialized, and
test for it again while wlock()ed; making sure the configuration
is read only once.
Also, rdconf() used to check for a undocumented "fsdev:\n" string
at the beginning of config data tho that was never documented.
This changes mconfig() to ignore that particular signature so
the example from the manpage will work as documented.
The sunStringUnpack() routine was miscompiled by 7c, as
pointer arithmetic is done in 64 bit but the constant -1
offset got expended to a unsigned 32 bit integer.
The expression value of the assignment operation was
returned implicitely by relying on regalloc() on the
right hand side "nod" borrowing the register from nn.
But this only works if nn is a register.
In case of 6c, it can also be a ONAME from a .safe
rathole returned by regsalloc().
This change adds explicit gmove() calls to assign the
expression value. Note that gmove() checks if source
and destination are the same register so it wont emit
redundant move operations in the common case.
The same is applied also to OPREINC and OPOSTINC operations.
Mutating lists that are being iterated is needlessly error
prone, and we were removing the wrong message in some cases
if it the dummy got inserted in the right place.
Separating deletion into a redraw/relink and zap phase
simplifies the problem.
Switching window focus used to be non deterministic
as the current window in focus (Window *input) was set
concurrently while processing window messages such as
Resized and Topped.
This implements a new approach where wcurrent() and
wuncurrent() are responsible for the synchronization
and switch of the input.
It is implemented by sending a Repaint message to the
old input window first, neccesarily waiting until that
window releases the focus and then input is updated
and then a Topped or Reshaped message is send to the
new input window.
Note, that when the whole screen is resized that no
input changes need to happening anymore.
This change makes the text window be focused on startup when using
default riostart (e.g: when using the release ISO). This little change
makes you able to immediately reach the rc shell without clicking the
window, which at the very least is more convenient, and if you have
problems to use your mouse but want to install the system, you also
can (I had to stop profile from running at boot to patch it in my VPS
KVM console because the mouse wasn't working properly. Could install
and setup it to connect through drawterm).
let pci.c deal with the special cardbus controller bar0 and
expansion roms.
handle apic interrupt routing for devices behind a cardbus slot.
do not free the pcidev on card removal, as the drivers
most certanly are not prepared to handle this yet.
instead, we provide a pcidevfree() function that just unlinks
the device from pcilist and the parent bridge.
When deleting messages that came in just
the right order, we would end up stuck in
a loop deleting and reinserting a dummy
parent, rather than the messages we wanted
to remove.
p.kosyh writes:
Hello! I finally bought rpi4 4Gb specially for 9front. It seems,
that default bpp of framebuffer is 16. I changed it to 24 (via
cmdline.txt and config.txt) and found, that rendering is much faster!
(May be due removing overheads in 16->24 conversions?)
But on rpi4 r and b channels are swapped. So, i changed BGR24 to
RGB24 in bcm/screen.c and now it works fine!
Sacrifice some of the sub-millisecond timer precision in favor of less
cpu load when the timer is about to be kicked a bit early. Result is
visible *especially* when the guest idling.
Timer proc *still* has to send to the channel (in order to kick PIT
and RTC logic), which takes time, and compensates a bit for possibly
early runs.
tftpd currently unconditionally sets its namespace via /lib/namespace
(newns("none", nil)), which stymied my attempts to pxe boot the
openbsd installer without creating a real /etc dir on 9front, which
would've been gross.
I tried working around this with -h (and -r for good measure), but
again hit issues because the namespace is rebuilt from scratch -- any
binds of /386, /amd64, /cfg/pxe, etc. into the tftp-specific directory
disappeared from tftpd's namespace and rendered my *9front* boxes
unable to boot. I could maintain copies of the needed files in the
tftp-specific directory, but that'd be kind of a drag.
The following patch adds a -n flag to allow the specification of a
namespace file in place of /lib/namespace; similar to ip/ftpd.
I thought about setting up a /lib/namespace.tftp to act as a default
rather than continuing to use /lib/namespace by default (which
security-wise is about the same as allowing 9p mounts by user none,
which I also have disabled), but I had trouble coming up with a sane
default. Maybe someone more experienced would like to try that out.
- sam-d
IndexField is supposed to increment the index value when an
access is done with a bigger size than the data field.
The index value is always a byte offset.
Now that we always calculate the offset for each field unit
access for IndexField, rename the indexv to bank (the bank
value), as it is only used for that. Also, do not compare
it with nil, as it is a integer constant which can be
encoded as nil to mean zero.
For BankField, the banking field was written using store(),
which does nothing when the destination is a Field*.
Use rwfield() to fix it in the new rwfieldunit().
Resolve all the Name*'s when IndexField, BankField and
Field are created. Now, Field.reg points to eigther
Buffer object, Region or Field (data Field of an IndexField).
PS: initial bug report by Michael Forney follows below:
In /dev/kmesg on my T14, I saw a message
amlmapio: [0xffffff18-0x100000018] overlaps usable memory
amlmapio: mapping \_SB.FRTP failed
Here is the relevant snippet from my DSDT:
Scope (_SB)
{
...
OperationRegion (ECMC, SystemIO, 0x72, 0x02)
Field (ECMC, AnyAcc, NoLock, Preserve)
{
ECMI, 8,
ECMD, 8
}
IndexField (ECMI, ECMD, ByteAcc, NoLock, Preserve)
{
Offset (0x08),
FRTB, 32
}
OperationRegion (FRTP, SystemMemory, FRTB, 0x0100)
Field (FRTP, AnyAcc, NoLock, Preserve)
{
...
}
}
With some debugging output:
amlmapio(\_SB.ECMC): Io 72 - 74
rwreg(\_SB.ECMC): Io [72+0]/1 <- 8
rwreg(\_SB.ECMC): Io [72+1]/1 -> 18
amlmapio(\_SB.FRTP): Mem ffffff18 - 100000018
amlmapio: [0xffffff18-0x100000018) overlaps usable memory
amlmapio: mapping \_SB.FRTP failed
It seems that libaml does not handle IndexField correctly and just did
a single read from ECMD after setting ECMI to 8, causing the FRTP
region to be evaluated as 0xffffff18-0x100000018. Instead, it should
be reading 4 bytes [18 c0 22 cc], evaluating it as
0xcc22c018-0xcc22118:
amlmapio(\_SB.ECMC): Io 72 - 74
rwreg(\_SB.ECMC): Io [72+0]/1 <- 8
rwreg(\_SB.ECMC): Io [72+1]/1 -> 18
rwreg(\_SB.ECMC): Io [72+0]/1 <- 9
rwreg(\_SB.ECMC): Io [72+1]/1 -> c0
rwreg(\_SB.ECMC): Io [72+0]/1 <- a
rwreg(\_SB.ECMC): Io [72+1]/1 -> 22
rwreg(\_SB.ECMC): Io [72+0]/1 <- b
rwreg(\_SB.ECMC): Io [72+1]/1 -> cc
amlmapio(\_SB.FRTP): Mem cc22c018 - cc22c118
I wrote a patch (attached) to fix this, and it seems to work. Though,
it's not clear to me when things should be dereferenced. Previously,
the data field was dereferenced at evalfield, but the region and index
field were not until rwfield. After the patch, the index field is
also dereferenced in evalfield.
For BankField, the index *is* dereferenced in evalfield. I'm pretty
sure that this means that BankField does not work currently, since
store() just returns nil for 'f' objects. The bank selector will
never get set.
Anyway, I don't know if this solves any real problems; it's just
something I noticed and thought I'd try to fix.
When the save folder did not exist, and we could not create
it, we would handle up to one Biobuf worth of message, and
then fail, due to a failed tee. The sequence of events leading
up to this was:
openfolder() -> error
tee(0, fd, -1) -> wait for read
write(0, data) ->
write(fd, data) -> ok
write(-1, data) -> error, tee terminates
write(0, attachment) -> error
This change prevents us from writing to a closed fd, and
therefore from erroring out when sending.
We also warn the user.
---
To: 9front@9front.org
Date: Sun, 07 Feb 2021 14:56:39 +0100
From: kvik@a-b.xyz
Subject: Re: [9front] transient dns errors cause smtp failure
Reply-To: 9front@9front.org
I think I found a reason for DNS failing on known good domains.
/sys/src/cmd/ndb/dns.h:156,157
/* tune; was 60*1000; keep it short */
Maxreqtm= 8*1000, /* max. ms to process a request */
So, 8 seconds is how much the resolver will bother with a request it
has been handed, before dropping it on the floor with little
explanation.
It seems quite possible that this is too short a timeout on a machine
during a spam queue run, which predictably stresses the compute and
network resources.
In turn, negative response caching might explain why a particular
unlucky domain would basically stop receiveing any mail for a while.
I'm dying to know if bumping this limit would clear up the queue of
such DNS errors.
---
[narrator: it did.]
* Add the %ll length modifier,
* Convert nil to "<nil>" under %s (not in APE),
* Cast void* to uintptr under %p,
* Use "0x" hex prefix under %p,
* Fix manual page mentions of %P to %p,
* Fix empty result for fp conversions,
* Fix zero padding of left-aligned fp conversions,
* Remove deprecated #pragma ref uses.
Most of these were introduced in APE prior to 9front.
I've omitted the %z conversion specifier since Plan 9 code
rarely uses the usize type. This may need to be added later
for the benefit of native ports of alien code.
I'm not sure if this LFSR is the same one used by the hardware or is
arbitrary, but it matches the noise sequence used by all other snes
emulators I looked at.
s1 and s2 should store the last and next to last output, but were set
in the wrong order, causing them both to be the last output. This
breaks filters 2 and 3, which both utilize s2.
despite the kernel never doing any efi runtime service calls,
overriding the runtime service regions makes some machines
lock up. so consider them reserved.
the boot service regions should also, in theory, be usable
by the os, but linux says otherwise...
fseeko returns 0 on success, not the new stream position.
This allows flacenc to update the streaminfo block when it is finished
(for example to set the number of samples and checksum).
There may be two iso endpoints with the same ID if it is asynchronous
or adaptive (one for data, one for feedback), and rw iso endpoints are
unusable (error out with "iso i/o is half-duplex").
There may be two iso endpoints with the same ID if it is asynchronous
or adaptive (one for data, one for feedback), and rw iso endpoints are
unusable (error out with "iso i/o is half-duplex").
The value of `k` in dtoa() is an estimate of
floor(log10(d)), where `d` is the number being
converted. The code was asserting that 'k' was
less than 100, but the full range of a double
goes to 10^308 or so.
This means that the majority of the range of
a double would trigger that assert.
validateattachment has no business with the mime boundary; it is not
part of the attachment itself.
Also, it causes the boundary to be dropped in the message output from
upas/vf, effectively dropping the following attachment (though the
content is still present after the last boundary of the wrapped first
attachment part).
Consider the following sequence of events:
1. upas/vf is run on a message containing two attachments.
2. The first attachment does not have a known extension, so is saved
to a temporary file *including* the following mime boundary.
3. This file is opened as p->tmpbuf, which is used for subsequent
reads until switching back to stdin.
4. The attachment fails validateattachment, so upas/vf wraps it in a
multipart with a warning message.
5. problemchild() calls passbody(p, 0), which copies from p->tmpbuf
until it hits the outer boundary line, which it excludes, seeks
back one line, then returns the outer multipart.
6. problemchild() then writes its own boundary, and then copies one
line from *stdin* to stdout, expecting the outer boundary.
However, this boundary was already read from stdin in 2, so it ends
up reading the first line of the subsequent part instead.
To fix this, pass 0 to passbody() in save() to exclude it from the
attachment file and make it available in stdin when expected.
Reading nested subparts of messages into the root
message array allows deeply nested multipart trees
of messages to show correctly in the message view.
H-blank DMA should only transfer 16 bytes per h-blank, rather than
waiting for the first h-blank and then transferring the whole size.
HDMAC should read 0xff when the transfer is finished, and 0 in the
high bit when the transfer is ongoing. Also, if 0 is written in the
high bit, the current transfer should be aborted.
Introduce two flags, DMAREADY and DMAHBLANK rather than special
constants 1 and -1. If dma is non-zero, there is an ongoing DMA. If
DMAREADY is set, the next chunk is ready to transfer.
Reference: https://gbdev.io/pandocs/#ff55-hdma5-cgb-mode-only-new-dma-length-mode-start
Tested with pokemon crystal.
What was happening is that when the game was loading N background tiles
into vram (each 16 bytes, so one per h-blank), it did something like
this:
- start an hdma transfer for N+1 tiles
- after the Nth tile is transferred, it would read HDMA5, clear the
high bit, then write it back to abort the transfer.
games/gb would instead transfer all N+1 tiles at once, overwriting one
extra tile with whatever was 1 past the end of the source array, and
then would interpret the cancel request as the start of a new transfer
of 16 bytes, which would copy an additional tile past the end. The end
result is that every transfer would end up copying N+2 tiles instead
of just N, overwriting certain tiles with whatever was after the end
of the source data.
According to [0], input clock 0 should divide by 1024=2¹⁰, not 2¹².
This caused audio to run at quarter-speed in one game I tried.
[0] https://gbdev.io/pandocs/#ff07-tac-timer-control-r-w
Tested with zelda: oracle of seasons, and dr. mario
---
upas/vf was converted to use tmdate, but the formatter was never
installed. This caused it to send attachments to validateattachment
with header `From virusfilter %τ%`, which always failed since upas/fs
would just skip over the message.
On the pi400, the xhci reset firmware mailbox request
assumes that the pci windows match the ones specified
in the device tree. The inbound window (pcidmawin)
also varies now depending on the amount of memory
installed.
It is all pretty ridiculous, as the firmware could as
well just read the pci controllers hardware register
to determine the window configuration and the os could
keep a nice simple 1:1 mapping (with pci dma addresses
== physical addresses).
The old parser code was rubbish and only worked for trivial
expressions. The new code properly handles complex expressions,
including short circuit evaluation.
As such, the BUGS section has been removed from the test(1) man page.
The description of an unimplemented feature has also been removed.
Despite pervious efforts, mk clean still doesn't remove libcommon.a*
files from cmd/upas/common/. To fix this, let's tell cmd/mklib to do
the job instead.
Runq spawns a number of processes, and wait()s for them
in 2 different places. Because of the way that the exit
handling is done, the wait can get the wrong message.
It turns out that only one place in the code needs to
wait for the child, and in all other cases, it's just
muddling the problem.
This change adds the RFNOWAIT call to all the processes
we don't need to wait for, so that the places that do
need wait will always get the correct child.
Screenlock should use libdraw(2) to init the display
and create the window, instead of looking at the screen
file directly. Also, to prevent new windows from popping
up over screenlock, bring it to the top periodically.
