Re: lpr woes printing a broken pdf

[Bryan Linton]

On 2021-11-02 16:10:44, Jan Stary  wrote:
> This is current/amd64 on a PC, using lpr with this /etc/printcap:
> lp::lp=:rm=pr.stare.cz:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:sh:
> which is a Brother DCP9055CDN via ethernet.
> 
> Now, I have this pdf file (attached), broken in a way that puzzles me.
> When viewed with mupdf or gv, it shows one thing, when printed with lpr,
> it shows something else.
> 
> [snip]
> 
> Is that an indication of some particular kind
> of breakage in a pdf file?
> 
> [snip]
>

I have no idea if this is the same issue affecting you, but it
reminded me of how JBIG2 compression can alter text.

To quote Wikipedia [1],

"When used in lossy mode, JBIG2 compression can
potentially alter text in a way that's not discernible as
corruption. ... Since JBIG2 tries to match up similar-looking
symbols, the numbers "6" and "8" may get replaced, for example."

This issue first came to light when it was found that scanned
documents had different numbers in the digital representation than
were on the original.  In one case, an engineer reported that the
size of a room on a technical blueprint changed from 21.11 m^2
down to 14.13 m^2 due to the way that the compression was being
erroneously applied.

However, this was reported when *scanning* documents.  Your issue
is with *printing* documents.  I have no idea if this is the same
issue as what you're experiencing, but I thought it still might be
worth pointing out in case there's some connection between the
two.

[1] https://en.wikipedia.org/wiki/JBIG2#Disadvantages

-- 
Bryan

Re: X220 thinkpad battery issue

[Bryan Linton]

On 2021-07-15 08:57:32, Isak Holmström  wrote:
> Hello,
> I recently discovered that my battery is not charging. I really can’t find 
> anything when searching the web regarding openbsd and batteries. Please 
> advice me how to debug this issue. I cannot find anything on 
> https://marc.info or man sysctl, apm or apmd, sysctl.conf 
> 

A couple thoughts.

1)  The battery may simply be dead.  AFAIUI, modern laptop
batteries have internal circuits that disable the battery if they
detect anything that could be dangerous.  There may be a
(Windows-only) utility that Lenovo offers to check this.

2)  Have you upgraded the laptop's internals, or changed the power
charger you use?  I know that newer models of Thinkpads will
refuse to charge if the charger can't put out enough power to do
so.  Lenovo makes chargers in many different wattage ratings.  Is
the one you're using rated to power an X220 in the configuration
it's in?  I.e. Models with faster CPUs/discrete graphics often
require a higher wattage power supply than those without.

3)  Power sockets get plugged and unplugged a lot, and tend to
wear out over time.  Could the socket itself be loose?  Does
"sysctl hw.sensors" show hw.sensors.acpiac0.indicator0 as being
"on"?  Does wiggling the power cable cause it to
connect/disconnect?

None of these are a definite answer, but hopefully one of them
will help guide you to a solution to your problem.

-- 
Bryan

Re: Unconsistent two-level write speed bouncing on softraid RAID1 SSD's

[Bryan Linton]

On 2021-06-10 11:49:59, Xavier Sanchez  wrote:
> 
> Read somewhere that issuing a security erase could also help. So I
> tried issuing the following:
> 
> # atactl sd0c secsetpass user high  
> User password:   
> Retype user password:
> atactl: ATA device returned error register 0 
> 
> But any sec* command returned:
> atactl: ATA device returned error register 0
> 
> even after a coldboot ( non-frozen ), despite the devices supports the
> Security Mode feature set
> 
> - Am I attempting to issue the security erase the wrong way ?
> 

This is not possible on OpenBSD.  It's actually a feature, not a
bug.  OpenBSD issues the secfreeze command at the driver level
when disks attach.

>From atactl(8):

secfreeze
  Prevents changes to passwords until a following power cycle.
  The purpose of this command is to prevent password setting
  attacks on the security system.  After command completion any
  other commands that update the device lock mode will be aborted.


You can see in src/sys/dev/ata/atascsi.c:408 and
src/sys/dev/ata/wd.c:305 that the same command is issued to all
sd(4) and wd(4) drives as a security measure.

You're going to need to boot from a live CD/USB in order to set a
password on the drive.

You should also double-check that your BIOS doesn't have a setting
to disable this too.  I've heard that some BIOSes have a toggle
for this to help mitigate the above-mentioned password setting
attacks.

Also, another poster mentioned that these are SMR drives.  If
that's the case, then the "stuttering" speeds you described is
normal for them.  SMR drives are good for storing infrequently
accessed files.  They're big and they're cheap, but they're not
always very fast.

Like the old saying goes when it comes to hard drives, "Pick any
two: cheap, fast, big".  SMR drives write data in "stripes".  If
you change even one bit of one byte anywhere in that stripe, the
drive has to read the entire stripe into memory, change what was
changed, then re-write the entire stripe.

This is a limitation of the technology they use.  It allows very
high density drives, but has the drawback of slowing things down a
lot whenever the drive has to re-write a stripe of data.


I've personally found that SMR drives are good enough for my use
case, but I wouldn't recommend them for a live database where
latency is much more critical.

It seems like the new hierarchy is now:

SSD >> PMR > SMR

when it comes to speed.  The inverse is true when it comes to
capacity.

So to summarize, your drive may be working exactly as intended.

-- 
Bryan

Re: phonetics on OpenBSD: IPA transcription

[Bryan Linton]

On 2021-01-08 20:42:20, Jan Stary  wrote:
> Is there anyone doing phonetics on OpenBSD?
> 
> [...]
> 
> If there are actualy phoneticians running on OpenBSD,
> how do you do it?
> 
>   Thank you
> 
>   Jan
>

Hello,

I wrote about my setup in an email to misc@ about a year ago.

https://marc.info/?l=openbsd-misc=153960218915258=2

(You may need to manually set your browser to UTF-8 to see
the line of IPA symbols in it.)

In brief, I installed ports/inputmethods/uim and use it to switch
into IPA layout.  I can write IPA symbols in both GUI and terminal
applications, though getting the symbols to show up correctly in
terminals requires a little more work.

Base vi doesn't support them, but nvi from ports works fine.
Trying to type commands into (n)vi while in IPA mode obviously
doesn't do what one expects though, so be sure to switch out of
it first.  I don't use emacs or mg, so can't comment on whether or
not they support them, but I suspect emacs most likely does.

I switch between layouts with either CTRL-shift or ALT-shift, and
then type according to the X-SAMPA rules which are documented in
/usr/local/share/uim/ipa-x-sampa.scm
which is installed by the uim port mentioned above.

Hopefully the above should get you a good working setup.  At the
very least, I'd recommend that you get your system set up to allow
X-SAMPA input since that seems to be the universal standard for
reducing the IPA into ASCII.  That way, no matter what system you
type IPA on, you'll have a consistent layout and won't need to
relearn anything.

Hope this helps!

-- 
Bryan

Re: Programmed wakeup from suspend/hibernate

[Bryan Linton]

On 2020-12-24 10:31:22, Ian Darwin  wrote:
> On Thu, Dec 24, 2020 at 11:51:26AM +0100, Gabriel Hondet wrote:
> > Hi,
> > 
> > How can I program my computer to automatically wake from suspend to ram
> > or suspend to disk at a certain time?
> > 
> > My goal is to suspend a server every day from, say, 11 pm to 7am.
> 
> For suspending at night, use see the cron man page.
> 
> For waking up in the morning, of course, the OS isn't running so there is 
> nothing
> it can do. Some but not all PC BIOSes have a scheduling feature. Otherwise a
> $10 mechanical timer to cut the power (well after the suspend is finished!) 
> and
> turn it back on in the morning.
> 

If shutting down the server entirely (instead of suspending it)
were an option, you could schedule a cron job to shut it down at a
given time and send a WoL (Wake on LAN) packet from another
computer on the network to wake it up again.

Oh, I just skimmed the ifconfig manpage and found the following:

wol Enable Wake on LAN (WoL).  When enabled, reception of a 
WoL frame will cause the network card to power up the
system from standby or suspend mode.  WoL frames are sent
using arp(8).

So it looks like you could even do this while the system were
suspended if your network card supports it.  Of course, this
depends on having another server on the same, physical LAN as the
server in question, so the mechanical switch suggestion above might be
the only option if that's not the case.

-- 
Bryan

Re: vmd eating lots of memory

[Bryan Linton]

On 2019-07-25 13:01:28, Mike Larkin  wrote:
> On Thu, Jul 25, 2019 at 09:54:22PM +0200, Paul de Weerd wrote:
> > A little more follow-up on this vmd-memory-leak issue.
> > 
> > Comparing the two VMs I have running, I started to stress parts where
> > these two hosts differ.  The testvm hardly does any traffic, while the
> > undeadly vm sees quite a few visitors on a daily basis, so networking
> > may be part of the leak.
> > 
> > Running tcpbench against this machine (averaging at ~250Mbit/s)
> > results in vmd growing by about 80MB to 100MB per minute.  Running
> > tcpbench against the testvm has similar results.
> > 
> > The undeadly VM also has a second disk configured (on slower storage),
> > but putting load on that didn't significantly change the memory
> > consumption (above the 'expected' growth that I've been seeing).
> > 
> > The growth during daily(8) runs still confuses me, as that doesn't do
> > anything network-related...
> > 
> > Paul
> > 
> 
> I'll try to look for leaks in that area then. Thanks for the report.
> 
> -ml
> 

To Paul, is it related to disk activity on the VM?  I.e. Does
doing lots of I/O on the system cause memory usage to increase?
Can you test it with a snapshot/kernel dated May 7th or earlier?

I CCed both of you into a bug report I just submitted to bugs@
because I thought it may possibly be related.

https://marc.info/?l=openbsd-bugs=156412299418191=2

In brief, I'm seeing large amounts of memory being consumed
followed by a system hang when files are copied to a vnd(4)
device.

I don't see it with regular disk I/O, only with vnds.

If the VMs are using/accessing memory in a similar way to the
method that vnd(4) does, it might explain why the daily(8) runs
are causing the memory usage to increase.

If this is an unrelated issue, then I apologize for the noise.  I
figured it better to CC both of you in so you could evaluate it on
your own rather than for me to do nothing.

-- 
Bryan

Re: phonetic alphabet on OpenBSD

[Bryan Linton]

On 2018-10-14 20:56:05, Jan Stary  wrote:
> Are there any phoneticians running on OpenBSD?
> How do you type the phonetic alphabet in vim?
> Is there a standard keyboard layout for the English part of IPA?
> 
> I wrote me an ipa.vim ftplugin with shortcuts (such as imap ,ae)
> for the unicode chars, but I am looking for a "standard" way.
> 
>   Thank you
> 

I use ports/inputmethods/uim with both terminal and GUI applications
and it works just fine.

I have it set up to use both anthy (for Japanese input) and IPA
(via X-SAMPA input).  CTRL-Shift gets me Japanese, and then ALT-Space
gets me IPA input.  Japanese input works just fine in the terminal,
and so does IPA input.

Sometimes it's difficult to figure out what key inputs what, in
which case I look through /usr/local/share/uim/ipa-x-sampa.scm

ˌɪntɚˈnæʃənl̻ fʌˈnɛtɪk ˈælfəˌbɪt

I just typed that with my keyboard (no copying or pasting) though
I had to have the above-mentioned ipa-x-sampa.scm file open to
reference some of the diacritics :)

I would imagine that any IME (like UIM or SCIM) would be the 
most "standard" way to do things.  It certainly beats copy/pasting
things (as I've done before on occasion).

-- 
Bryan

Re: Installed current on top of FAT32 flash, Recover old filesystem??

[Bryan Linton]

On 2018-07-14 12:16:53, Chris Bennett  wrote:
> I very carefully and surely tested which flash drive to use and then
> pulled out the wrong one.
> I stopped the install with halt and done nothing else.
> Should I have yanked it, halted it or just said goodbye?
> 

Ouch...  Sooner or later, I think most all people will do
something that will cause loss of data, so don't feel too bad.
The good news is that it usually only happens once, because most
people will find an event like this to be a very strong motivator
to implement additional backup strategies.  It certainly was for
me...

Ordinarily, yanking it would've been the best thing to do, since
halting the system would've flushed more data to the disk that
wouldn't have been written if it had just been yanked, but IIRC
the OpenBSD install program mounts disks synchronously so I don't
think it would've made much difference in this case.

I remember reading a guide about this long ago on the net, and the
first suggested step of data recovery was,

1. PANIC!

The reason being that it's better to take a step away from one's
computer and do the panicking AWAY from the computer so as not to
exacerbate the situation and cause even more data loss by doing
something hasty.

Once that's done, I can only offer some general advice.

The good news is that the OpenBSD installation is only about 300
MB.  If it was a network install then you may have to double that
(~300 MB to hold the tarballs, ~300 MB to hold the installation).
That means that you very likely have only lost less than a
gigabyte of data.  Depending on how big and how full the flash
drive was, that may leave a significant amount of space that will
still be intact.

The writing of alternative superblocks in the newfs stage would've
probably poked lots of little holes in the data all over the disk.
If you stored large files on the disk, it's likely that they may
have small bits of them that were overwritten.

On the other hand, if you had many small files, it's more likely
that the majority of them will still be intact.

> ddrescue or something else or nothing else?
> 

>From what I can tell, ddrescue is meant more to recover data from
a failing disk; not one that has been overwritten.

But first things first, make a COPY of your drive with dd RIGHT
NOW!  Anything you do to try to recover anything should be done on
the copy, not the drive itself.

Once that's done, something like sysutils/testdisk is probably
more in line with what you're looking for.

% cat ports/sysutils/testdisk/pkg/DESCR
TestDisk is a powerful free data recovery software! It was
primarily designed to help recover lost partitions and/or make
non-booting disks bootable again when these symptoms are caused by
faulty software, certain types of viruses or human error (such as
accidentally deleting a Partition Table). Partition table recovery
using TestDisk is really easy.

PhotoRec is a file data recovery software designed to recover lost
files including video, documents and archives from Hard Disks and
CDRom and lost pictures (thus, its 'Photo Recovery' name) from
digital camera memory. PhotoRec ignores the filesystem and goes
after the underlying data, so it will still work even if your
media's filesystem has been severely damaged or re-formatted.
% 

So it looks like PhotoRec is probably the one you want.

If you need to find your old disklabel (so you know what the
bounds of the disk were) you can try looking in /var/backups.

There should be several "disklabel.*.{backup,current}" files in
there that may contain the disklabel for the drive.  Though I
think those are only created as part of the /etc/daily script run
by cron, so the disk would've had to have been plugged into the
computer when it was run.

If you use multiple disks that would share the same device node
(e.g. /dev/sd3) you could also try looking in /var/mail/root which
would log any changes to those files in the daily insecurity
report.

Other than that, it's almost guaranteed that at least *some* data
was lost.  Depending on the nature of the data, you may be able to
find some scraps of it on your main hard drive too.

Text editors and word processors tend to create backup files, so
looking around for any files that end in ".bak" or a tilde might
provide some results.  Checking vi.recover might also be worthwile
if you were typing anything important in vi.

Once you get through this, I can recommend a few things that may
help to mitigate this in the future:

1) Backup your USB drives to a directory on your hard disk
regularly.  rsync is a good simple tool for this, though
borgbackup is nice too.  Bonus points if you automate it through
hotplug(4).

2) Since manual backups don't tend to get done as often as
necessary, set up an automatic backup system.  rsnapshot is a good
tool for this that runs from cron (it's a thin wrapper around
rsync).  borgbackup is also nice too.  It's less convenient to
access the files since its FUSE support doesn't seem to work on

Re: Flatbed scanner that works well with OpenBSD?

[Bryan Linton]

On 2018-01-19 21:59:09, Bryan Linton <b...@shoshoni.info> wrote:
> Hello misc@
> 
> I'm currently looking to purchase a scanner that works well with OpenBSD.
> 

I want to thank all the people who replied in this thread.

I tried searching for some of the models several posters recommended,
but unfortunately they seem to be too old to be found at the places I
looked.

I think my best bet is to find a cheap all-in-one device that can scan
directly to USB and just make use of that.

Thanks again to all who replied!

-- 
Bryan

Flatbed scanner that works well with OpenBSD?

[Bryan Linton]

Hello misc@

I'm currently looking to purchase a scanner that works well with OpenBSD.

I'm aware of the list provided at: 

http://www.sane-project.org/sane-mfgs.html

but I recently purchased (and returned) a scanner that was listed as being
fully supported on that list because no matter what I did, I couldn't
get it to work right with xsane or scanimage.  Though I purchased it used,
so it's possible it may have simply been broken from the get-go.

Does anyone happen to know of a scanner that is *known* to work well
with OpenBSD?

I don't really have any hard requirements other than it should be able
to scan in color as well as black and white, and should be able to scan
up to a minimum of 600 dpi (1200 dpi or more would be nice, but is not
required).

I have a feeling that the majority of scanners currently on the market
meet or exceed that, so hopefully anything will work well so long as it's
compatible with OpenBSD.

Many thanks for any assistance anyone can provide.

--
Bryan

Video-conferencing tool a la Skype or Facetime for OpenBSD?

[Bryan Linton]

Hello misc@

I have a friend who runs Windows who has asked me if there is any
way we can occasionally communicate with each other via some kind 
of video-conferencing application similar to what programs like
Skype and Facetime provide.

Does such a thing already exist for OpenBSD?

My requirements are fairly simple:
1) Must be usable between OpenBSD and Windows.
2) Must transmit/receive audio and video from a webcam.
3) Should be as point-and-click (on the Windows side) as possible.
4) Bonus points if it contains a text-based chatting feature.

For number 3, I can drive over to my friend's house and do a one-time
setup of anything highly technical, but after that, it should be as
simple for them as possible.  They're moderately technically inclined,
so entering a server/port/etc. is well within their means, but configuring
port-forwarding in their firewall and the like is something I'd have to
do myself.

Looking through the ports tree, I see a few programs that look promising,
like telephony/baresip but I don't see anything like Ekiga or Empathy.

Before I put the effort in to trying to get something working, I thought
it'd be prudent to ask the list if such a thing is even feasable first.

Any pointers (even a, "No, this isn't possible yet with OpenBSD <-> Windows")
would be appreciated.

Thank you!

-- 
Bryan

Re: Japanese Input in xterm

[Bryan Linton]

On 2017-10-15 09:38:56, Niels Kobschaetzki  wrote:
> On 17/10/15 07:12, Niels Kobschaetzki wrote:
> > On 17/10/15 06:41, Niels Kobschaetzki wrote:
> > > Hi,
> > > 
> > > I am trying to get Japanese input working in xterm but I just cannot get
> > > it to work. It works in xfce4-terminal though.
> > > 
> > > I have in my .profile and my .xsession:
> > > export LANG=en_US.UTF-8
> > > export LC_NUMERIC=de_DE.UTF-8
> > > export LC_TIME=de_DE.UTF-8
> > > export LC_MONETARY=de_DE.UTF-8
> > > export LC_PAPER=de_DE.UTF-8
> > > export LC_NAME=de_DE.UTF-8
> > > export LC_ADDRESS=de_DE.UTF-8
> > > export LC_TELEPHONE=de_DE.UTF-8
> > > export LC_MEASUREMENT=de_DE.UTF-8
> > > export LC_IDENTIFICATION=de_DE.UTF-8
> > > export LC_CTYPE=en_US.UTF-8
> > > 
> > > export GTK_IM_MODULE=ibus
> > > export XMODIFIERS="@im=ibus" xterm
> > > export QT_IM_MODULE=ibus
> > > 
> > > I am not sure though what exactly is necessary now because I tried now a
> > > lot to get it working.
> > > 
> > > In my .Xdefaults I have:
> > > XTerm*faceName: Terminess Powerline:style=Medium
> > > XTerm*faceSize: 13
> > > xterm*faceNameDoublesize: Sazanami Mincho
> > > XTerm*utf8: true
> > > XTerm*locale: utf8
> > > XTerm*inputMethod: ibus
> > > 
> > > When I have ibus-anthy activated the pop over appears and I can type
> > > Japanese but when I hit enter to place it, no characters appear. When I
> > > want to open a japanese web page like https://www.asahi.com in lynx
> > > there are only garbled characters (and w3m crashes).
> > > 
> > > A mail in Japanese appears correctly in mutt though.
> > > 
> > > What I am missing?
> > 
> > I got a bit further. When I start xterm with "xterm -cjk_width" it works
> > \o/
> > 
> > But setting "XTerm*cjkWidth: true" in .Xdefaults has no effect (yes, I
> > do a xrdb -merge .Xdefaults)
> 
> And now I found yet another issue. The moment I use
> xterm*faceNameDoublesize the character "ü" breaks and the line-drawing
> characters on the bottom of the index of mutt break as well
> 

I have mostly the same settings as you do in .xinitrc, except I
use UIM instead of ibus.  Everything works well for me.

What do you mean when you say, "when I hit enter to place it, no
characters appear"?  Does nothing happen at all?  Or do you see
dotted rectangles instead of kanji? 

I use two different commands to launch xterms depending on whether
I want to use Japanese or not.  In the normal xterm, I can input
text and create documents, but I see dotted rectangles because I
use the default font.  If I view that file with the proper fonts
after creating it, it's fine, so I know the input is being
properly sent and recorded.

I have a jxterm.sh command contaning the following command:
env LC_ALL=ja_JP.UTF-8 xterm -fa "Sazanami Gothic" -fs 16 $1
that I run whenever I want to explicitly use (and see) Japanese.

I do this because I prefer the default font in xterms for Latin
text, and the Japanese font is too big for my tastes.  For
Japanese it's the other way around.  A bigger font is necessary to
show the detail of kanji.  Either way, it's only a display issue
and I can edit documents even if the font doesn't display them
properly.

Does this work if you try using UIM?  What about SCIM?

UIM seems to be moribund.  There have been some recent commits,
but the last release was in 2015.  The current release does not
work with QT5.  I brought this up on ports@, since recent commits
have enabled QT5 support, and it was suggested that I contact
upstream and ask them to make a proper release.

I attempted to do so, but it seems like whoever is in charge is
not there any more.  I was only able to contact a Debian
maintainer, who said they do not have the power to create a full
and proper release, so it looks like SCIM might be a better choice
than UIM.

-- 
Bryan

Re: Xbox 360 controller emulators/snes9x hangs at startup

[Bryan Linton]

On 2017-09-22 12:36:56, Bryan Linton <b...@shoshoni.info> wrote:
> On 2017-09-22 08:24:32, Stefan Sperling <s...@stsp.name> wrote:
> > 
> > Can you compile a kernel with sys/dev/usb/uhid.c reverted to
> > older revisions to test your hypothesis?
> > 
> 
> This issue has already been reported and mpi@ is working on a
> solution.  The beginning of the relevant parts of the thread
> starts with the following email:
> 
>   https://marc.info/?l=openbsd-ports=150563553805569=2
> 

Aaand no sooner do I send the above email and mpi@ posts a patch
to ports@ which seems to fix the issue for me.

I encourage anyone affected to test the following patch and report
back success or failure:

https://marc.info/?l=openbsd-ports=150608393026201=2

-- 
Bryan

Re: Xbox 360 controller emulators/snes9x hangs at startup

[Bryan Linton]

On 2017-09-22 08:24:32, Stefan Sperling  wrote:
> 
> Can you compile a kernel with sys/dev/usb/uhid.c reverted to
> older revisions to test your hypothesis?
> 

This issue has already been reported and mpi@ is working on a
solution.  The beginning of the relevant parts of the thread
starts with the following email:

https://marc.info/?l=openbsd-ports=150563553805569=2

To OP: I, and others, have provided mpi@ with more debugging
information that he's asked for.  I don't know if he needs any
more information or not, but I don't think snes9x has been run
with the patches he's supplied yet.

It may be worthwhile to apply the patches he's sent, and then
forward on the information you get so as to help debug things.

-- 
Bryan

Re: Dumb question about updating snapshots

[Bryan Linton]

On 2017-08-25 13:09:14, Jordon  wrote:
> I’ve been running snapshots on my machine for a while now.  About once or 
> twice a week I will interrupt the boot with ‘bsd.rd’ and run through the ‘U’ 
> process to get the latest builds.  The only weirdness is that it alway 
> defaults to a really slow mirror (i have to manually enter a different one) 
> and it simply doesnt work when I enter a number from the list.  Is this a 
> proper way to update?
> 
> What about when the version gets bumped?  Since the switch to 6.2, this 
> method doesn’t work because it doesnt give the list of packages - just the 
> kernel ones.  Is this expected behavior and the solution is to boot from a 
> flash drive or PXE from the latest 6.2 media?
> 

The older bsd.rd is probably only looking for files tagged with
its own version.  I.e. If you have 6.1 installed, it's looking
for base61.tgz and not base60.tgz or base62.tgz.

There are probably quite a few different ways to update to new
snapshots.  What I've been doing for a long time now is the
following:

1) Fetch latest snapshot from a local mirror, and save to HDD
2) Verify with signify
3) Copy /bsd and /bsd.rd to /bsd.old and /bsd.rd.old respectively
4) Copy the snapshot's bsd.rd to /
5) Reboot, select bsd.rd, and select 'U' for upgrade
6) When given the option to select where filesets are
   located, answer that the partition is already mounted
   (since in my case, I put them on /var, so it already is
   mounted) and manually type in the full pathname to the
   sets.

I wrote a basic shell script that does 1) and 2) all at once, so I
can just run "fetch-snap.sh" and it automatically backs up the
previous snapshot, fetches the new one, and verifies everything.

The process I use above does not seem significantly different to
what you're already doing, at least when compared to the
alternative of using a USB stick, so I'd recommend you consider trying
it.

If you have another machine on your local network, you could run a
minimal httpd instance and make said directory available to them.
I do this too, so I upgrade my main machine with the above steps,
but point all other machines on my local net to the local IP
address of the main machine when asked to choose a mirror and
proceed as normal.

I've not had any problems with this procedure in the many years
I've been using it, but YMMV.

-- 
Bryan

Re: Lenovo T440s

[Bryan Linton]

On 2017-08-02 15:17:17, and...@quickstick.net wrote:
> First of all, big thanks to Theo for his strong leadership and to all the
> past and present devs !!! Have a great week ahead !!!
> 
> 
> ---
> 
> Just a little FWIW from a Lenovo T440s ...
> 
> ---
> 
> dmesg | sort | uniq -c
> 
>   1 3834:intel_uncore_check_errors] *ERROR* Unclaimed register before 
> interrupt
>  30 error: [drm:pid31067:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
> 124 error: [drm:pid45200:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
> 474 error: [drm:pid53834:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
>  48 error: [drm:pid76233:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
>   9 error: [drm:pid77807:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
>  26 error: [drm:pid85895:intel_uncore_check_errors] *ERROR* Unclaimed 
> register before interrupt
>

I see the same thing on a T440p.  I reported it on tech@ when a
call for testing was put out, so the developers involved should be
well aware of the issue.

The above errors don't seem to be causing any negative effects,
and the new drm code is still being worked on and improved, so I'm
content to simply wait for progress to be made or until another
patch and/or call for testing is made where I can be involved more
actively.

A few extra lines of harmless dmesg spam are a small price to pay
for having all the work the developers put in to bring newer drm
code and Skylake support to OpenBSD.

I extend my own thanks to all those involved in such a feat.

-- 
Bryan

Re: Good looking fonts in Java apps

[Bryan Linton]

On 2017-07-19 06:39:04, Bernard Mentink  wrote:
> Thank Bryan,
> 
> I guess that would have to go in .kshrc? I think that is the default shell
> for OpenBSD right?
> 

It would depend on the shell you're actually using.  If you
haven't installed or aren't using another shell, then .kshrc is
what you would want.

You could also try temporarily testing this by opening an xterm
(or whatever terminal program you prefer) and setting that
environment variable, and then launching your browser from within
the terminal so it picks up the new environment variable.

If it fixes the fonts, then you can set it permanently by putting
that line in .kshrc.

-- 
Bryan

Re: Good looking fonts in Java apps

[Bryan Linton]

On 2017-07-18 13:19:27, Bernard Mentink  wrote:
> Hi Guys,
> 
> I am running a Java app launched by javaws (IcedTea-web) and am finding the
> fonts terrible, does anyone know how I can get better anti-aliased fonts?
> 

I don't know about javaws, but for regular stand-alone Java
applications I had to use the following to get fonts that were
anywhere close to readable.

export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on'

I added it to the shell-script running the program itself.  You
may need to put this in your .${SHELL}rc file (.kshrc, .zshrc,
.bashrc, etc.) instead if this is running inside of your browser.

If it doesn't work, hopefully it will at least give you a good
starting point to try other things.

-- 
Bryan

Re: Characters of various Asian languages not rendering correctly in Firefox and Chromium

[Bryan Linton]

On 2017-06-17 19:34:40, Daniele D'Accurso  wrote:
> Hello altogether,
> 
> first of all I would like to apologize if a fix for my issue is
> already publicly documented but I did not manage to find it before.
> 
> So for some reason, in all gecko-based browsers (Firefox, Seamonkey)
> and in Chromium, I cannot display Chinese (Traditional and
> Simplified), Korean and Japanese characters, instead they are rendered
> as squares.
> 
> [...]
>

Since you only see this issue in browsers, and not in any other
software, my first instinct would be to try with a blank profile.
In Firefox, run "firefox --profilemanager" and try creating a new,
blank profile.  There should be a similar way to change profiles
in Chromium.

If that works, then try disabling all your extensions and see if
your original profile works.  If it does, re-enable the extensions
one-by-one (if you have a lot, try enabling them in batches of 10
or so) and try to see if one of them may be responsible.


Which version of Firefox are you running?  If you're running the
main branch, does installing the ESR branch work?  Vice-versa?


Do you have any other fonts installed besides the noto- fonts?  I
have the following fonts installed for Japanese text.  If you
don't have them installed, does installing them help?

ja-kanjistrokeorders-ttf-3.001p0 font to view stroke order diagrams for Kanji, 
Kana and etc
ja-mplus-ttf-20060520p5 high quality Japanese truetype fonts
ja-sazanami-ttf-20040629p3 japanese true type fonts


Beyond that, I'm not sure what else to suggest.  I don't have any
problems with Firefox displaying any CJK characters, though I'm
running OpenBSD-current.

Upgrading to a snapshot and seeing if that makes any difference
would be a simple way to see if anything in -current has fixed the
issue you're seeing too.


Hopefully you can manage to narrow down the issue.  If you do,
please send a follow-up email to the list so that the archives
will have it and others can search for it if they hit the same
problem.

-- 
Bryan

Thinkpad T440p cannot be unmuted via Fn keys with mplayer in some cases

[Bryan Linton]

Hello misc@

I'm not sure if I should send this to bugs@ or not, so I decided
to send this here first.

I recently bought a Thinkpad T440p to replace my aging T60 model
and encountered some non-intuitive behavior.  I think the behavior
of the volume keys has been discussed before, but I don't remember
what the conclusions were.

On my T60, the volume up, volume down, and mute keys behaved as if
the buttons connected to an external speaker on a desktop.  I.e.
I could press them and the OS and X11 were completely oblivious to
any changes.  Everything seemed to be handled by the BIOS behind
the OS's back.

On the T440p however, these keys seem to be passed through to X11
and/or the OS itself, which makes for some odd bugs.


Case #1:

1) Mute the system by pressing Fn+F1.  A light on the F1 AKA "Mute
key" turns on to show the system is muted. 
2) "mixerctl outputs.master.mute" shows as "on".
3) Play a video in mplayer.  It plays muted.
4) Oops!  I want my audio, so I press Fn+F1 to unmute the system.

Expected result:
The system is unmuted, and audio plays normally.

Actual result:
The *system* does actually unmute itself.  outputs.master.mute
shows as "off".  However, mplayer picks up the button press, and
now *mplayer* is muted!

Press the button again, and mplayer successfully unmutes itself
but... now the *system* is muted again.

Sometimes I get a brief, split-second of audio when doing this,
but usually no audio plays at all.

This only happens when using mplayer to play a video.  When using
it to play audio, the xterm it's running in does not react this
way and it unmutes itself as in the "Expected result" above.


Case #2:

0) Mute the system before the OS is loaded.  The "mute light"
turns on.
1) Run "mixerctl outputs.master.mute" and it shows
"outputs.master.mute=off"
2) Press the button again.  The "mute light" turns off (indicating
the system should not be muted) but now outputs.master.mute shows
"on".

Expected result:
The "mute light" and "mixerctl outputs.master.mute" should always
be in a congruent state.

Actual result:
The "mute light" and "mixerctl outputs.master.mute" can and do end
up in contradictory states.


Case #3:

1) Set volume to something below the maximum, *outside* of an
mplayer window.
2) Play a video with mplayer.
3) Press mplayer's "volume up" key (NOT the Fn-combination) to set
mplayer's volume to the max.
4) One can now press the Fn keys to increase the volume beyond the
supposed "max" in mplayer.
5) Try to decrease the volume with the Fn-combination and now
mplayer "catches" the key and ALSO decreases its own, internal
volume as well.  I.e. The Fn-keys seem to have double the effect.
Once on the system as a whole, and again after mplayer intercepts
them.

Expected result:
The Fn-combinations should behave as if a knob on an external set
of speakers is being turned, and the OS and applications within
the OS should have no knowledge of their state.

Actual result:
The button presses are passed through to the OS, where they appear
to have a double effect.  The Fn keys can also continue to
increase the volume even after mplayer says it's at maximum
because they're still decoupled at some level.


Summary:
As stated above, while there may be other users who would
disagree, I tend to expect hardware buttons like these to behave
as if I'm twiddling a knob on an external stereo or set of
speakers.

Regardless of how they're treated, it would probably be best if
only one of the BIOS or OS were made aware of them.  As it stands
now, it appears that *both* the BIOS and the OS see the button
presses, which results in the non-intuitive behavior seen above.


Suggested fix:
Uncertain.  I'm not sure if the problem is with the computer
itself, acpithinkpad.c, X11, or with mplayer.  It may even be a
combination of the above.


Addendum:
I'm running the latest BIOS from Lenovo.

dmesg is attached below signature.  I know that custom kernels are
frowned upon, but the only change made is the addition of the
PPPOE_TERM_UNKNOWN_SESSIONS option, which is practically a
requirement for me if I don't want to wait 5-20 minutes for my
internet connection to time-out after rebooting.  I'm making a
semi-educated guess and assuming it would not affect the
audio-subsystem, but I can re-test on a GENERIC.MP kernel if
necessary.

-- 
Bryan


OpenBSD 6.1-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #11: Tue May 23 
19:10:56 JST 2017

shoshon...@shoshoni-m.shoshoni.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS
real mem = 12539871232 (11958MB)
avail mem = 12154036224 (11590MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbcc0d000 (67 entries)
bios0: vendor LENOVO version "GLET85WW (2.39 )" date 09/29/2016
bios0: LENOVO 20AWS27D00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT 

Re: Etnernal & infernal browser woes

[Bryan Linton]

On 2017-04-29 17:28:33, Sebastien Marie <sema...@online.fr> wrote:
> On Sat, Apr 29, 2017 at 11:21:25PM +0900, Bryan Linton wrote:
> > 
> > One hack I've done when I don't care about actually getting or
> > using a corefile from large programs is to do the following:
> > 
> > # rm progname.core
> > # touch progname.core
> > # chflags uchg progname.core
> > 
> > Of course, I'd only recommend doing so if one is absolutely
> > certain they don't want a corefile from said program ever again,
> > and will remember to unset that flag should they ever change their
> > mind.
> > 
> 
> If you want to disable core dump for a program, you could (should ?)
> configure your RLIMIT_CORE to 0.
> 
> $ ulimit -c 0
> $ firefox
> 

Ah, yes.  That's a much better solution.  I overlooked that that
option was available.  Thank you for the pointer! :)

-- 
Bryan

Re: Etnernal & infernal browser woes

[Bryan Linton]

On 2017-04-29 15:48:51, Ingo Schwarze  wrote:
> 
> Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500:
> 
>> Firefox [...] takes a long period to actually finish crashing
> 
> It dumps core.  That takes a long time because firefox tends
> to waste huge amounts of memory [...]
> 

One hack I've done when I don't care about actually getting or
using a corefile from large programs is to do the following:

# rm progname.core
# touch progname.core
# chflags uchg progname.core

Of course, I'd only recommend doing so if one is absolutely
certain they don't want a corefile from said program ever again,
and will remember to unset that flag should they ever change their
mind.

-- 
Bryan

Re: pppoe takes 3 or 4 minutes to come up

[Bryan Linton]

On 2017-04-02 10:42:07, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2017-04-02, Bryan Linton <b...@shoshoni.info> wrote:
> > If this is truly due to the modem itself not having sync, then I
> > doubt the following option will help, but I've found that in my
> > case I need to have the kernel option PPPOE_TERM_UNKNOWN_SESSIONS
> > added to my kernel build in order to avoid long time-outs if I
> > reboot my machine for instance.
> 
> Problem is that the pppoedev ethernet interface comes down too soon and
> the pppoe disconnect message can't be sent. A fix for this was being
> discussed but late for 6.1. "ifconfig pppoe0 down" in rc.shutdown should
> help that situation for now.
> 

That's actually a nice tip to have for now.  Thanks!

-- 
Bryan

Re: pppoe takes 3 or 4 minutes to come up

[Bryan Linton]

On 2017-04-02 10:47:41, Konstantin Schukraft  wrote:
> Hello,
> 
>> I am using pppoe on OpenBSD 6.0 stable to setup a connection
>> to Deutsche Telekom (VDSL). Problem: Usually it takes 3 or 4
>> minutes to establish the connection. Is this as expected?
> 
> I'm in the same situation. The problem seems to lie with with VDSL,
> the modem takes a long time compared to the old ADSL modems to 
> synchronise with the DSLAM on the other side; 2 minutes are not unusual.
>
> [...]
>
> I already contemplated asking on this list if there is a way to 
> modify these wait periods, since I can't find anything in the 
> documentation.
> 

If this is truly due to the modem itself not having sync, then I
doubt the following option will help, but I've found that in my
case I need to have the kernel option PPPOE_TERM_UNKNOWN_SESSIONS
added to my kernel build in order to avoid long time-outs if I
reboot my machine for instance.

By default, the kernel will not send a PADT request to terminate
the old PPPoE session in order to not interfere with other PPPoE
sessions.

"man 4 pppoe" explains this better than I could.  To wit:

8<---

KERNEL OPTIONS
 A pppoe enabled kernel will not interfere with other PPPoE
 implementations running on the same machine.  Under special
 circumstances (details below) this is not desirable, so the
 pppoe driver can be told to kill all unknown PPPoE sessions
 received by the Ethernet interface used for a configured
 pppoe interface.  To do this, add the following to your
 kernel config file:

option PPPOE_TERM_UNKNOWN_SESSIONS

 This option is only useful if you have a static IP address
 assigned and your ISP does not use LCP echo requests to
 monitor the link status.  After a crash or power failure the
 peer device still tries to send data to the no longer active
 session on your computer, and might refuse to reestablish a
 new connection, because there already is an open session.  On
 receipt of such packets, the pppoe driver with this option
 set will send a PADT packet (request to terminate the
 session).  The peer will immediately disconnect the orphaned
 session and allow a new one to be established.

8<---

Again, this option is only meant to apply in very specific
circumstances, which is likely why it is not the default.  I only
mention it because it seems like it might be worthwhile to see if
it fixes the issues you're seeing.  Though as I stated above, if
this is due to the modem itself not having sync with the DSLAM,
then I doubt that it will have any effect.

As always, the standard disclaimer applies to anyone who modifies
their kernel.

-- 
Bryan

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Bryan Linton]

On 2016-10-15 02:03:54, Joel Sing  wrote:
> 
> The number of rounds specified for bcrypt_pbdkf(3) is linear, not logarithmic 
> (unlike bcrypt(3)). That said, the processing required for each round is 
> significantly higher than that of pkcs5_pbkdf2(3) (using `bioctl -r auto -v` 
> will tell you rounds your machine will do in ~1s).
>  

Ah, good to know.  Thank you for the correction!

-- 
Bryan

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Bryan Linton]

On 2016-10-14 09:21:24, Peter Janos  wrote:
> Hello,
> 
> [snip]
>
> ps.: it would be nice to have a feature in the default installer to install
> with full disc encryption :) we still have to escape to shell during install
> and ex.:
> 
> install60.iso
> (S)hell
> dmesg | grep MB # or: sysctl hw.disknames
> dd if=/dev/urandom of=/dev/rsd0c bs=1m # not needed, only for paranoids
> dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
> fdisk -iy sd0
> disklabel -E sd0
> a a
> enter
> enter
> RAID
> w
> q
> bioctl -c C -l /dev/sd0a -r 2000 softraid0
> # use a random high iteration number x > 10 000 000
>

I just want to point out (for the archives as well as others) that
the softraid crypto discipline has recently been switched from
PBKDF2 to bcrypt.

http://marc.info/?l=openbsd-cvs=147430724911779=2
http://www.openbsd.org/faq/current.html#r20160919

Since bcrypt calculates its rounds based on the exponentiation of
the number (i.e. the default of 16 rounds actually performs 2^16
rounds or 65536 rounds), the default number of "rounds" was
reduced from 8192 to only 16.  If you were to use 20 million
"rounds" with the new bcrypt algorithm, I wouldn't be surprised if
it took weeks, months, or even YEARS to actually mount your disk
after inputting your password.

For reference, I tried to simply calculate 2^20 millionth power
using dc for my own amusement and gave up after it crunched numbers
for over a minute with no answer returned.

A value of 24 (2^24 or 16,777,216) or 25 (2^25 or 33,554,432)
would probably be closer to what you actually want.

> exit
> Start install to the newly created bioctl/crypt raid device: sdX, where X is
> ex.: 2...
> 
> with a random (but very high) number for iteration, afaik iteration only
> counts when typing in the password, much higher iteration would slow down
> brute-force attackers.
> 

Indeed it would.  Quite significantly in fact.

-- 
Bryan

Re: Route add - too many levels of symbolic links

[Bryan Linton]

On 2016-09-27 20:00:04, Dekker  wrote:
> I have started encountering a wierd problem with my OpenBSD Laptop
> Running 6.0 Current (latest snapshot 25.09.2016)
> I run OpenVPN to connect this laptop to a remote server and I get the
> following output.
>

[snip]
 
> I also receive the 'Too many levels of symbolic links' errors when I
> connect to alternate (known working) OpenVPN servers.
> If I connect to these known working servers with my Android phone the
> route add command succeeds and I can access the interal networks behind
> the OpenVPN servers
> 
> If I try to add these routes manually I get the same message: Too many
> levels of symbolic links.
> 
> What could be the root cause of this issue?
> 

Please see this thread/post on ports@
http://marc.info/?l=openbsd-ports=147385901603925=2

Note that sthen@ said he was looking at some other issues as
well, so this may not be the final patch that gets committed, but
it fixed OpenVPN for my use case at least.

Your milage may vary.

-- 
Bryan

Re: em0 interface hangs in 5.7

[Bryan Linton]

On 2015-05-23 14:02:33, Riccardo Mottola riccardo.mott...@libero.it wrote:
 Hi Christian,
 
 Christian Schulte wrote:
 after upgrading my T60 from 5.6-stable to 5.7-stable, I am experiencing the
 same issue described above. Should this be filed using sendbug ? I am
 currently reverting to the athn0 interface which is working fine. The em0
 interface hangs after some minutes or even seconds and isn't usable as of 
 5.7.
 
 I too have a T60, I upgraded to 5.7 and I just used em0 and it works fine.
 I had a ssh connection open to a server farm for 16 hours without problem,
 in the meanwhile I did browse the web, checked email several times,
 everything fine and the ssh connection is still up.
 

This was already patched in -current
http://marc.info/?l=openbsd-cvsm=143146204227681w=2

It was mentioned that this only affects certain em(4) chips.  Namely 
the 82573, ICH8, and 82542.  If you have one of these chips, you *will* 
experience this issue if you use the machine long enough.

I could go for days, sometimes a week or more without seeing it, but
it would eventually hit this bug (particularly when under high CPU
loads).

Your dmesg should tell you what kind of chip you have.

My T60:
em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi...

My X61t: 
em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x03: msi...

If you hit this bug, upgrading to -current will fix it.  If you cannot run
-current, I am not a developer and do not aim to speak for them, but you
*may* be able to backport this fix yourself and compile a new kernel since
this change was rather unobtrusive:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_em.c.diff?r1=1.296r2=1.297f=h

Obviously, I make no claims about how this might affect a production system,
and you would be running a system with a kernel that, due to it mixing
-current and -RELEASE sources, would probably not receive support by others
on the lists.

Nevertheless, it is an option of last resort if you have one of the above
chipsets and start hitting this bug, and cannot upgrade to -current for
whatever reason.

-- 
Bryan

Re: jwm ; speedy window manager

[Bryan Linton]

On 2015-04-06 09:59:29, Tuyosi Takesima nakajin.fu...@gmail.com wrote:
 thanks fo reply .
 i understand jwm's state at present.
 
 openbsd's default X window manager(i don't know it's name) is
 difficult to use especially non-english language user .
 
 it's defect is that it doesn't show the state of input method.
 jwm show the state of input method(right under) and speedy .
 

If you're talking about CWM, then what I do to see what input
method is currently being used with UIM is to check the Show
input mode nearby cursor option in the Global settings menu
(the default one that opens up with running uim-pref-gtk) and set
it to With time and set the time length to 1 second (you could
set it to a longer time, but 1 second is enough for me).

It also has the option of With mode which shows it permanently
next to the cursor, but only when switched away from the default
IME.

This causes the input mode to show every time I change focus on a
window.  The only bug I notice with this is when using TCL/TK
applications, the input mode shows up every time I hover over a
text field or button (like OK, Cancel, etc.) which sometimes
blocks a click, but I don't use many TCL/TK applications, so it's
not a major issue for me.

Of course, this would only apply if you're using UIM.  If you're
using SCIM or something else, then you'd have to see if they have
their own options for showing what the current IME is.

-- 
Bryan

Re: recommended input methods?

[Bryan Linton]

On 2014-12-11 22:46:48, Joel Rees joel.r...@gmail.com wrote:
 On Thu, Dec 11, 2014 at 10:07 PM, Joel Rees joel.r...@gmail.com wrote:
  Followup:
 
  On Tue, Oct 14, 2014 at 2:02 PM, Joel Rees joel.r...@gmail.com wrote:
  What're the recommended input methods for Japanese and Spanish?
 
  I have got Japanese input running and useable, by installing the packages
 
  ja-fonts-gnu
  ja-sazanami-ttf
  ja-mplus-ttf
  ibus-anthy
 
  with pkg_add . I'm not comfortable that this is the most optimal way
  to do it, but it allows me to work on an openbsd box.
 
 I should note, that I have to launch the ibus preferences (as from
 Setings in XFCE4) to get the ime daemon started at this point. Haven't
 found out how to get it to start when X11 starts.
 

I use UIM, not ibus, but I have the following lines in my .xinitrc
(among several others which are not relevant here) which starts
UIM automatically when X is started.

export XMODIFIERS=@im=uim
export GTK_IM_MODULE=uim
export QT_IM_MODULE=uim

env LC_CTYPE=ja_JP.UTF-8 uim-xim 

exec env LC_CTYPE=en_US.UTF-8 /usr/X11R6/bin/cwm

If you play around with these, you could probably get something
working with ibus.

For GTK at least, I think these module names are currently sourced
from either:
/usr/local/lib/gtk-2.0/2.10.0/immodules
or
/usr/local/lib/gtk-3.0/3.0.0/immodules

And are cached in /etc/gtk-2.0/gtk.immodules by running
gtk-query-immodules-2.0.  It seems like GTK-3 is doing something
different, maybe under ~/.config or something or just running
gtk-query-immodules-3.0 directly.  It works for me, so I haven't
really looked into it much.

Note that some applications refuse to accept Japanese input unless
they're run with the correct locale settings *AND* an overridden
input module, so I have

bind C-g env GTK_IM_MODULE=xim LC_CTYPE=ja_JP.UTF-8 gwaei

in my .cwmrc so that a Japanese dictionary program of all things
will accept Japanese input.

As I said before, unfortunately xombrero needs the same hack
#bind C-x env GTK_IM_MODULE=xim LC_CTYPE=ja_JP.UTF-8 xombrero
but this makes the fonts very ugly on most pages and in the
general UI.  I'm still hoping to find some way to get it to
support Japanese input without needing to force the locale to
change, since it seems like Firefox, xterms, and most any non-GTK
programs just Do the Right Thing (TM).

I find it somewhat ironic that I was able to get Japanese
input/output in xterm/irssi/mutt/tmux working with less than 5
minutes of reading manpages, but have spent literally hours
getting GTK to work.

GTK apps used to Just Work (TM), but it seems like after new
versions have been released over the last few years, more and more
hacks have been needed to keep things working.  First it was only
the LC_CTYPE=ja_JP.UTF-8 that was needed, now GTK_IM_MODULE=xim is
needed too.

I'm sure the GTK developers have good reasons for continually
changing these, but it's certainly inconvenient to upgrade GTK and
find that one's IME stops working.

Once again, any cluebats are appreciated, but I have a feeling
this is just how things are WRT needing all these environment
overrides.

I hope you're able to get ibus to start automatically from this
information.  If not, maybe try giving UIM a try?

--
Bryan

Re: recommended input methods?

[Bryan Linton]

On 2014-10-14 14:02:52, Joel Rees joel.r...@gmail.com wrote:
 What're the recommended input methods for Japanese and Spanish?
 

I can't speak for anything officially recommended, but for
Japanese at least, I use ports/inputmethods/anthy with
ports/inputmethods/uim and it works well.

The only complaint I have is that for some applications, namely
xombrero and xfe, they either do not accept Japanese input unless
their locale is specifically changed to Japanese, such as is the
case with xombrero, which has the side-effect of changing all
fonts to Japanese equivalents which makes for rather ugly font
choices made for the Latin alphabet, or in the case of xfe where
it just does not accept Japanese input at all no matter what I
have tried.

An xterm invoked as uxterm and started with a Japanese font allows
me to have a terminal which supports the input and display of
Japanese however, so I'm not quite sure what keeps xombrero and
xfe from working out-of-the box like Firefox, editors/leafpad, and
devel/geany, for example.  If anyone knows, please let me know.

I do have 
export XMODIFIERS=@im=uim
export GTK_IM_MODULE=uim
in my .xinitrc file.


As far as Spanish is concerned, I simply have a dead-key set up in
my .xinitrc
setxkbmap -rules base -model pc105 -option compose:menu
which sets the menu key in-between the right-ALT and right-CTRL
keys to a dead-key such that pressing MENUa will produce an
'a' with umlauts.  There are many other combinations as well.

You could probably use uim to to switch between a Spanish layout,
but it might be easier to do that with setxkbmap if you're
planning on typing in Spanish a lot, and are not just in need of
an occasional extended-Latin character.  If you'll only
occasionally need an extended-Latin character, then using a
dead-key would probably be the easiest route.

I'd be interested in what other people use for the above tasks as
well.

Hope this was helpful!

-- 
Bryan

Re: Semi-reproduceable em0 network hangs in new snap

[Bryan Linton]

On 2014-09-06 23:13:51, Bryan Linton b...@shoshoni.info wrote:
 Hello list,
 
 [dmesg and ifconfig output attached inline at bottom]
 
 I upgraded from a mid-July snapshot to a recent one, and I've been
 experiencing a strange problem with the network losing
 connectivity that I haven't been able to pin down.
 
 What happens is the machine (a Thinkpad T60) will lose all network
 connectivity, even to the point where pinging local machines or
 the default gateway will produce no response.  
 
 A simple ifconfig em0 down up will restore connectivity.  There
 are no errors in the dmesg, and ifconfig em0 shows the interface
 as up and running when connectivity is lost.
 
 Fetching email with ports/mail/fdm (I haven't tried any other
 MDAs) will usually cause the hang to occur.  Strangely, regular
 web browsing doesn't seem to be very likely to cause this.
 
 Does anyone have any idea of things I can do to try to isolate
 this?  I've looked through the CVS logs since mid-July and nothing
 jumped out at me as being particularly likely to cause this.
 
 Thank you.
 
 -- 
 Bryan
 
 
 OpenBSD 5.6-current (GENERIC.MP) #330: Thu Sep  4 02:53:34 MDT 2014
 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 cpu0: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
 cpu0: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
 real mem  = 2682613760 (2558MB)
 avail mem = 2626367488 (2504MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 04/01/10, BIOS32 rev. 0 @ 0xfd6b0, 
 SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
 bios0: vendor LENOVO version 79ETE6WW (2.26 ) date 04/01/2010
 bios0: LENOVO 2623D9U
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
 acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
 EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpiec0 at acpi0
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 166MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
 cpu1: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 1
 acpimcfg0 at acpi0 addr 0xf000, bus 0-63
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (AGP_)
 acpiprt2 at acpi0: bus 2 (EXP0)
 acpiprt3 at acpi0: bus 3 (EXP1)
 acpiprt4 at acpi0: bus 4 (EXP2)
 acpiprt5 at acpi0: bus 12 (EXP3)
 acpiprt6 at acpi0: bus 21 (PCI1)
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
 acpitz0 at acpi0: critical temperature is 127 degC
 acpitz1 at acpi0: critical temperature is 99 degC
 acpibtn0 at acpi0: LID_
 acpibtn1 at acpi0: SLPB
 acpibat0 at acpi0: BAT0 model 92P1139 serial   659 type LION oem Panasonic
 acpibat1 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit online
 acpithinkpad0 at acpi0
 acpidock0 at acpi0: GDCK docked (15)
 bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 
 0xe/0x1!
 cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: apic 1 int 16
 pci1 at ppb0 bus 1
 radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 
 0x00
 drm0 at radeondrm0
 radeondrm0: apic 1 int 16
 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi
 azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog 
 Devices AD1981HD
 audio0 at azalia0
 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20
 pci2 at ppb1 bus 2
 em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 
 00:16:41:52:7e:81
 ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21
 pci3 at ppb2 bus 3
 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, 
 MoW1, address 00:13:02:20:41:18
 ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22
 pci4 at ppb3 bus 4
 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23
 pci5 at ppb4 bus 12
 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16
 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02

Semi-reproduceable em0 network hangs in new snap

[Bryan Linton]

Hello list,

[dmesg and ifconfig output attached inline at bottom]

I upgraded from a mid-July snapshot to a recent one, and I've been
experiencing a strange problem with the network losing
connectivity that I haven't been able to pin down.

What happens is the machine (a Thinkpad T60) will lose all network
connectivity, even to the point where pinging local machines or
the default gateway will produce no response.  

A simple ifconfig em0 down up will restore connectivity.  There
are no errors in the dmesg, and ifconfig em0 shows the interface
as up and running when connectivity is lost.

Fetching email with ports/mail/fdm (I haven't tried any other
MDAs) will usually cause the hang to occur.  Strangely, regular
web browsing doesn't seem to be very likely to cause this.

Does anyone have any idea of things I can do to try to isolate
this?  I've looked through the CVS logs since mid-July and nothing
jumped out at me as being particularly likely to cause this.

Thank you.

-- 
Bryan


OpenBSD 5.6-current (GENERIC.MP) #330: Thu Sep  4 02:53:34 MDT 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem  = 2682613760 (2558MB)
avail mem = 2626367488 (2504MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/01/10, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS 
rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version 79ETE6WW (2.26 ) date 04/01/2010
bios0: LENOVO 2623D9U
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 92P1139 serial   659 type LION oem Panasonic
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK docked (15)
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 
0xe/0x1!
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: apic 1 int 16
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00
drm0 at radeondrm0
radeondrm0: apic 1 int 16
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi
azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices 
AD1981HD
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 
00:16:41:52:7e:81
ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21
pci3 at ppb2 bus 3
wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW1, 
address 00:13:02:20:41:18
ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23
pci5 at ppb4 bus 12
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19
ehci0 at pci0 

Re: CWM has all groups application?

[Bryan Linton]

On 2014-06-12 18:35:05, Rodrigo Mosconi open...@mosconi.mat.br wrote:
 Hi guys,
 
 I would like to know if is possible to make an application (xclock, for
 example) to be always present, regardless the selected group.
 On my configuration I have a gap, where I place xclock without group.  When
 I use grouponlyN all applications hides (ok, described behavior),
 including xclock.
 
 Is possible to make xclock  present on all groups?
 
 I understood from cwm(1) and cwmrc(5) that an application can be member of
 only one group or no group.  Is that true?
 
 If does not exists allgroups, that feature is interesting to be added?
 
 Thanks
 

Since in another mail you sent to the list, you said you're using
snapshots, there was a bug introduced in CWM back in February that
prevents applications from being omnipresent.

I reported the bug, and was told by the developer in question that
they did not have time to track it down right now, but would as
soon as they had free time.
http://marc.info/?l=openbsd-bugsm=139536903917298w=2

In the meantime, you can use CVS to checkout a copy of CWM from
February 6th, 2014, and rebuild it.  It takes less than 10 seconds
to build on a CPU circa 2005.  In that case, provided that the
application doesn't automatically start assigned to a group, you
can press CTRL+ALT+MOUSE1 (CM-M1 in cwm(1)) to make windows
omnipresent.

-- 
Bryan

Re: Getting stylus working on Thinkpad X61 tablet

[Bryan Linton]

I'm curious about the specific model number, would you mind
sharing it and/or the dmesg?

Thank you.

-- 
Bryan

On 2014-04-28 15:43:13, Peter Hessler phess...@theapt.org wrote:
 yes, my new thinkpad edge works with the tablet perfectly fine.
 
 
 On 2014 Apr 27 (Sun) at 16:46:31 -0700 (-0700), Bryan Linton wrote:
 :Ping.
 :
 :Can anyone confirm or deny whether or not the newer Thinkpad
 :tablets' styluses work as an input device?  I see that there is a
 :usbtablet(4) driver in xenocara, with people reporting success
 :using external tablets, so it would probably be a matter of
 :whether or not the newer Thinkpads still use a serial-based wacom
 :device as opposed to a USB-based one.
 :
 :Since FreeBSD supports these serial based tablets with a kernel
 :module and the linuxwacom driver, I'm assuming that it's probably
 :going to require more than just a simple port to get this working.
 :
 :Even http://cgit.freedesktop.org/~whot/xf86-input-wacom/ which was
 :created after X.org removed the X.org wacom input driver in favor of
 :just using the linuxwacom driver says it still needs a driver to
 :bridge the kernel-userland parts.
 :
 :-- 
 :Bryan

Re: Getting stylus working on Thinkpad X61 tablet

[Bryan Linton]

On 2014-04-29 07:56:02, Bernte ber...@fams.de wrote:
 
 I own an X60t, and I did not manage to get it up and running. It was a
 long time ago and I cannot remember the details, unfortunately. I gave
 up because I also considered it not to be too important at that time.
 
 I might give it another spin and see how far I get. Now, with a second
 potential user, we might also get a proper problem description to the
 developers :-)
 

I mentioned this in my previous email, but it probably won't hurt
to rehash it.

The serial port is at a non-standard location, so using config(8)
to set com0 to address 0x200 and port 5 causes the serial port
connected to the screen to show up in the dmesg.

Connecting to it via cu(1) definitely shows data being sent when
the screen is written on, so I think it's only a matter of a
kernel and/or X driver being written.

Unfortunately, that is currently beyond my level of expertise, so
all I can do is offer to test anything somebody else decides to do.
Which basically boils down to, Talk is cheap, put up or shut up.

Since there's nothing more that I *can* do, I'm going to choose to
do the latter.  :)

-- 
Bryan

Re: Getting stylus working on Thinkpad X61 tablet

[Bryan Linton]

Ping.

Can anyone confirm or deny whether or not the newer Thinkpad
tablets' styluses work as an input device?  I see that there is a
usbtablet(4) driver in xenocara, with people reporting success
using external tablets, so it would probably be a matter of
whether or not the newer Thinkpads still use a serial-based wacom
device as opposed to a USB-based one.

Since FreeBSD supports these serial based tablets with a kernel
module and the linuxwacom driver, I'm assuming that it's probably
going to require more than just a simple port to get this working.

Even http://cgit.freedesktop.org/~whot/xf86-input-wacom/ which was
created after X.org removed the X.org wacom input driver in favor of
just using the linuxwacom driver says it still needs a driver to
bridge the kernel-userland parts.

-- 
Bryan

On 2014-04-21 16:26:36, Bryan Linton b...@shoshoni.info wrote:
 Hello list,
 
 [dmesg attached below]
 
 I recently purchased a Thinkpad X61 tablet (manufactured circa
 2006) and have not been able to get the stylus to work with the
 screen in OpenBSD.  It worked fine with the Windows 7 install that
 came with it, so I know the hardware itself is fine.
 
 From reading some old posts to misc@, I have used config to
 change the address and IRQ of com0 to 0x200 and IRQ 5, which has
 caused com0 to show up in the dmesg.
 
 If I run cu -l /dev/cua00 and write on the screen, I get output
 while I am writing that abruptly stops when I move the stylus
 away, so I think it's a matter of a driver issue between X11 and
 the hardware.
 
 Unfortunately, emails from the time-period suggest running the
 linuxwacom driver, which doesn't compile due to Linuxisms in the
 code.  Even the older releases don't compile on a modern system.
 
 Other posts have indicated that adding a wacom driver section to
 xorg.conf will work.  While there is a wacom(4) listed in
 xorg.conf(5), it is not installed on OpenBSD.  In fact, 
 % cd /usr/xenocara; find . -iname *wacom* -print returns
 nothing at all, and indeed none of the examples posted have worked
 or given any hint in Xorg.0.log that the tablet functionality is
 detected at all.
 
 Is there any way to get the tablet functionality to work on
 OpenBSD?  Is it simply a matter of a missing wacom(4) driver?  Do
 any of the later Thinkpad tablets (some of which I've read use USB
 connections internally instead of serial connections) work any
 better?
 
 I would really love to be able to use a stylus to write directly
 on the screen; writing complicated Japanese kanji with a mouse can
 become somewhat tedious after a while, so any help is greatly
 appreciated, even if it's only There are no plans to support this
 on OpenBSD so that I can start looking into another option (a PDA
 perhaps?).
 
 Thank you.
 
 -- 
 Bryan
 
 
 OpenBSD 5.5-current (GENERIC.MP) #43: Sat Apr 12 09:39:12 MDT 2014
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 cpu0: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 
 799 MHz
 cpu0: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
 real mem  = 3194179584 (3046MB)
 avail mem = 3129528320 (2984MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 03/22/11, BIOS32 rev. 0 @ 0xfdc80, 
 SMBIOS rev. 2.4 @ 0xe0010 (63 entries)
 bios0: vendor LENOVO version 7SET39WW (1.25 ) date 03/22/2011
 bios0: LENOVO 7764CTO
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF! SSDT 
 SSDT SSDT SSDT
 acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
 EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) 
 USB4(S3) EHC0(S3) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpiec0 at acpi0
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 199MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 
 1.60 GHz
 cpu1: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 1
 acpimcfg0 at acpi0 addr 0xf000, bus 0-63
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (AGP_)
 acpiprt2 at acpi0: bus 2 (EXP0)
 acpiprt3 at acpi0: bus 3 (EXP1)
 acpiprt4 at acpi0: bus -1 (EXP2)
 acpiprt5 at acpi0: bus -1 (EXP3)
 acpiprt6 at acpi0: bus -1 (EXP4)
 acpiprt7 at acpi0: bus 5 (PCI1)
 acpicpu0

Getting stylus working on Thinkpad X61 tablet

[Bryan Linton]

Hello list,

[dmesg attached below]

I recently purchased a Thinkpad X61 tablet (manufactured circa
2006) and have not been able to get the stylus to work with the
screen in OpenBSD.  It worked fine with the Windows 7 install that
came with it, so I know the hardware itself is fine.

From reading some old posts to misc@, I have used config to
change the address and IRQ of com0 to 0x200 and IRQ 5, which has
caused com0 to show up in the dmesg.

If I run cu -l /dev/cua00 and write on the screen, I get output
while I am writing that abruptly stops when I move the stylus
away, so I think it's a matter of a driver issue between X11 and
the hardware.

Unfortunately, emails from the time-period suggest running the
linuxwacom driver, which doesn't compile due to Linuxisms in the
code.  Even the older releases don't compile on a modern system.

Other posts have indicated that adding a wacom driver section to
xorg.conf will work.  While there is a wacom(4) listed in
xorg.conf(5), it is not installed on OpenBSD.  In fact, 
% cd /usr/xenocara; find . -iname *wacom* -print returns
nothing at all, and indeed none of the examples posted have worked
or given any hint in Xorg.0.log that the tablet functionality is
detected at all.

Is there any way to get the tablet functionality to work on
OpenBSD?  Is it simply a matter of a missing wacom(4) driver?  Do
any of the later Thinkpad tablets (some of which I've read use USB
connections internally instead of serial connections) work any
better?

I would really love to be able to use a stylus to write directly
on the screen; writing complicated Japanese kanji with a mouse can
become somewhat tedious after a while, so any help is greatly
appreciated, even if it's only There are no plans to support this
on OpenBSD so that I can start looking into another option (a PDA
perhaps?).

Thank you.

-- 
Bryan


OpenBSD 5.5-current (GENERIC.MP) #43: Sat Apr 12 09:39:12 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 799 
MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
real mem  = 3194179584 (3046MB)
avail mem = 3129528320 (2984MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/22/11, BIOS32 rev. 0 @ 0xfdc80, SMBIOS 
rev. 2.4 @ 0xe0010 (63 entries)
bios0: vendor LENOVO version 7SET39WW (1.25 ) date 03/22/2011
bios0: LENOVO 7764CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF! SSDT SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) 
USB4(S3) EHC0(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 
1.60 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus -1 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP4)
acpiprt7 at acpi0: bus 5 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB4, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4661 serial  1010 type LION oem SANYO
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0x1! 0xd/0x1000 0xd1000/0x1000 0xe/0x1!
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1601, 1600, 1200, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c
vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1400x1050

Re: Lenovo ThinkPad T60 won't resume

[Bryan Linton]

On 2010-11-01 21:36:04, Philip Guenther guent...@gmail.com wrote:

 [...]

 So, while that change hasn't been recommitted yet, if you're
 running into problems with suspend or resume on a box that it
 worked fine on before, some sort of worked with kernel from
 date1, failed on kernel from date2 really would assist in
 tracking this down.  And build from a clean directory. 


Suspend/resume mostly worked with the Aug 02nd snap and mostly
failed on the Aug 04th snap  :)

I guess you can call this a me too in that I've been experiencing
many of the same issues everyone else seems to have with their T60s.

There was a brief window in in late July/early August about a week
long where it would successfully suspend and resume, but the screen
would never turn back on.  Anytime before or after that and it
would suspend fine, but when it resumes it's totally unresponsive
to anything except a 4 second press of the power button.

I did a little bit of testing and sent a report to dmesg@ back
when the call for testing went out.  I've attached it to this mail
in case it might be useful.


NB, my T60 has a Radeon X1300 in it whereas the other two posters
in this thread have an X1400.  Not sure how relevant that is
in this case though...


-- 
Bryan

- Forwarded message from Bryan Linton b...@shoshoni.info -

Date: Fri, 6 Aug 2010 23:23:43 -0800
From: Bryan Linton b...@shoshoni.info
To: dm...@openbsd.org
Subject: IBM Thinkpad T60 w/ATI video, suspend works, resume works w/blank
screen, everything else OK
Content-Type: multipart/mixed; boundary=n8g4imXOkfNTN/H1
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Content-Length: 11265

With the Aug 02nd snap:
Suspend works fine but resume comes up with a blank screen.
Keyboard works fine after resume as evidenced by du /usr causing
the HDD light to blink with appropriate noises coming from the
HDD.  Ctrl-C stops this activity.  Also, either pressing Fn-F4 (the
key combination to suspend the laptop) or typing in apm -S or apm
-z successfully suspends the system again, coming back to a blank
screen upon resuming with a still working keyboard.

Wired network works fine, as evidenced by playing an audio file
over NFS, then suspend/resume, and still being able to seek all
the way to the end (and randomly).  This was an mp3 that was
several hundred megabytes in size so I don't think that buffering
would have pulled the whole file in.

However, after resuming, typing in halt, halt -p or reboot
cause a brief flicker of the HDD activity light and appear to
otherwise have no effect.  The system always fscks all filesystems
after having to hold the power button down for ~4 seconds to turn
it off.  halt -p and reboot work fine and have their intended
effects if the system has not been suspended.

There was no difference in behavior between bsd.sp and bsd.mp.
apmd was running during all these tests.  All tests were done at
the console.

The Aug 04th and Aug 05th snap show a regression in that suspend
works, but on resume the moon-shaped sleep LED blinks until the
machine is rebooted instead of turning off or staying solid green.
The screen is still blank, but the keyboard and network do not
work at all after resuming.

All other functionality is the same between the snapshots if the
machine has not been suspended.  Wired/Wireless networking, audio,
screen-brightness/volume buttons, etc. all work fine.



OpenBSD 4.8-beta (GENERIC.MP) #295: Mon Aug  2 19:32:22 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM
real mem  = 2682679296 (2558MB)
avail mem = 2628812800 (2507MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/01/10, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS 
rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version 79ETE6WW (2.26 ) date 04/01/2010
bios0: LENOVO 2623D9U
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2300 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0

OSS v4.0 released under BSD license

[Bryan Linton]

I just saw that OSS v4.0 has been released under a 2-clause BSD license. [1]

I haven't seen it mentioned on the list yet and I know there's been a lot
of audio related development going on in -current so I just thought I'd 
mention it for anyone who might be interested. Their website hasn't been 
completely updated to reflect the new BSDL-release, but the press release 
and COPYING file in [2] say it's for real.


[1] http://www.opensound.com/press/2008/oss-bsd.txt
[2] 
http://www.4front-tech.com/developer/sources/stable/bsd/oss-v4.0-build1012-src-bsd.tar.bz2