Anyone Interested In Prebuilt Bleeding Edge?

[iamasmith]

Hi,

I have patched my Zaurus quite a lot since I put OpenBSD on it and submitted most of these patches here.

To list a few patches..

https://www.oesf.org/forums/index.php?showtopic=17690 contains a fix to wsfb that correctly implements mode storage - there is a bug in the original driver where only the current mode was fixed up. In 640x480 screen mode a query of display modes via xf86vm queries would return 480x640. This patch fixes that. The original developer passes this behaviour off on XOrg issues - the XOrg issues that I know about are related to the GetViewPort extension which admittedly is still buggy - this isn't directly related to this issue. - Note that with this patch you will still need GetViewPortIsFullOfLies: True in ~/.xscreensaver if you are running it. - Longer term the original developer suggests that this will be fixed by XOrg fixing it..hmm.

https://www.oesf.org/forums/index.php?showtopic=17642 contains Caps Lock fixes that work in the Console and in X, the console fix is a Kernel patch to wskbd and the X patch is a fix to kbd_drv. The console  problem has been acknowledged by one of the OpenBSD guys and I expect that there will either be my patch or his own patch to correct the issue. The X patch hasn't been commended on by maintainer of the X stuff.

https://www.oesf.org/forums/index.php?showtopic=17428 contains a non Zaurus specific enhancement to the uvisor driver that may enable a sizable range of CLIE devices with OpenBSD. No acknowledgement as yet at all from the OpenBSD guys.

http://marc.theaimsgroup.com/?l=openbsd-ar...93195221600&w=2 Finally yet another patch (not posted here). It contains modifications to the zts driver to allow rotation to be implemented directly within the driver and also contains a command line utility to select touch screen rotation. This is to overcome the scaling flaw that effects OpenBSD on the Zaurus when the display is placed into Portrait mode. For a full description of the issue please read the thread. Again the X developer hopes to address this when OpenBSD finally adopts a speculative version of XOrg with new (note still being planned) extensions to support rotation handling for input devices. At the moment this I see as the cleanest workaround for the scaling issue since rotation can be applied directly to the zts driver without effecting the usb mouse driver that also runs through the same X driver.

OK, now the point of this message.

It is established that there is generally a lag in patch feed into OpenBSD because it's run by a core team and they want to QA and fix or dismiss patches for a variety of reasons.

It seems that particularly with regard to the X environment we may be in for something of a wait before we have some of the fixes implemented through the suggested channel of waiting until XOrg is fixed and does everything  - The maintainer has suggested that we will have xrandr support soon as a stopgap to some issue but we shall have to see what that brings with it.

I myself am enjoying the benefits of a Zaurus that runs a lot more cleanly in both the console and in X than with the stock distibution (subjective view of course) and have shared all my discoveries without even including the customary 'I was here and I fixed this' lines in the patches - in the end I just want to see these issues fixed and I don't care if they are fixed with my patches or somebody elses patches just as long as I don't have to wait forever for them.

So practically speaking I will probably patch every little annoyance that I come across on the Zaurus and it may be that some of these patches do get implemented in the distribution and some dont.

My question to you folks using OpenBSD on your Zauruses is this...

Do you want to accept a kernel binary that I will post periodically containing these fixes? I can post X drivers on this board without a problem but I think a prebuild kernel should be kept off these pages since it's too darned big and offroadgeek will be getting his guns off the rifle-rack if we really swamp these pages ().

If I do this then I can also place the X fixes up there too in binary form.

I will always include the patch source so that people can see what is going on and will probably patch and build each -current snapshot that emerges. In fact since I am using a Kernel based on a cvs sync rather than a snapshot the base kernel will be more recent anyway than the snapshots.

So what are your thoughts folks? Do you want this stuff posted somewhere so you don't have to build all that kernel stuff or do you just want me to post patches?

Incidentally running a custom Kernel doesn't rearrange your Zaurus in any way, you will simply either replace /bsd with the custom file or copy it to /bsd.custom you are then free to boot into either from the boot prompt. By default the boot prompt will boot /bsd. You can override this simply by typing an alternate Kernel name, you can copy over /bsd with a custom kernel or you can make a /etc/boot.conf to select an alternate configuration.

Anyway let me know what sounds good to you.

- Andy

[albertr]

I think running OBSD on the Z should be assumed as a sufficient proof of intelligence, so that person should be able to build from sources... Please continue to share your patches, but I don't really see the need for binaries of any kind at all.
-albertr

[iamasmith]

Wohooo, somebody knows where the reply button is , thanks for your comment Albert it's a good point.

Not all people want to spend time building the whole thing, the Kernel takes about 1hr from scratch over NFS but a clean build of X takes over night.

- Andy

[loc4me]

I would like to see the binaries posted for OBSD. I am very interested in trying new distros on the zaurus but i dont have the time or the environments set up ATM for me to cross compile the sources. I do like to tinker with my Z but i do not have the knowledge of the inner workings of a Linux or Unix system therefore i would not be building a distro from the source.

I follow this forum daily and love to see the experienced users making an effort to do things and help those of us who are still "just learning". I think it would be nice to see some binaries for OBDS that include these nice and helpful patches that Andy has gone through the trouble to incorporate.

Thanks for the offer Andy. I would like to see them.

-Mark

[tovarish]

i would like to see the binaries too since i have a slow laptop and less disk space than is usually needed to compile kernels and X servers

tovarish

[tg]

I would like to see the binaries posted for OBSD. I am very interested in trying new distros on the zaurus but i dont have the time or the environments set up ATM for me to cross compile the sources. I do like to tinker with my Z but i do not have the knowledge of the inner workings of a Linux or Unix system therefore i would not be building a distro from the source.

I follow this forum daily and love to see the experienced users making an effort to do things and help those of us who are still "just learning". I think it would be nice to see some binaries for OBDS that include these nice and helpful patches that Andy has gone through the trouble to incorporate.

Thanks for the offer Andy. I would like to see them.

-Mark
[div align=\"right\"][a href=\"index.php?act=findpost&pid=114845\"][{POST_SNAPBACK}][/a][/div]

I totally agree.
For me easy installation (ok maybe not quite cacko easy but close) is now a prerequisite to trying any new distros since I just don't have the time to set up build environments and mess with cross compiling etc.
Also, for me one thing I'm waiting for before switching to OBSD on Z are reports of smoothly running firefox on OBSD (so I'll probably have to stay on cacko+opera for a while longer since stable graphical browser is probably what I use the most these days).

[darkloran]

hello andy,

  it's a nice proposition to give access to compiled versions of kernel or X as it would take hours to build them for each of us.

  i'd be interested as others for binaries.

  so far i've built many packages but it seems i'm always two or three trains after you    your Z is so much improved that it's a lot faster than mine i feel  

  well what about ports? we agree that for better performance we have to compile ports on the Z and not take packages from arm feed but could we find a way to share our ports? in fact i wonder how to manage "versions" of compiled ports as i'm really new on OpenBSD.

thanks again for your work - i've been a cacko user for a long time before falling into the depths of obsd  

[iamasmith]

Ports are more of a problem with the -current distribution which we are running. Ports and dependencies are constantly being updated which typically means that if you build something new off the ports it may well update something that you alreay have. You may have found this out already.

The only feasible way of providing a large quantity of binary packages for ports is to use -release or -stable because of the amount of time that is needed to build them. I'm afraid that means running the base OS as -release or -stable and there are just too many benefits to running -current at the moment.

Perhaps this is an option for the future when the Zaurus distribution mature a little more in -release.

I have some additional difficulties with ports which I don't want to pass on to anyone else as a headache. I am running espgs instead of the ghostscript distribution from the ports. The reason for this is that it integrates with CUPS to render print output for a variety of printers (I am using it with an Epson stylus photo). The problem with this is that there are a great many ports/packages dependent upon Ghostscript so for my own builds I have to strip those depends from the Makefiles so that it doesn't try to install Ghostscript over the top of espgs which provides the same set of executables but isn't in the feed. This is a bit of a headache and as I say I don't really want to give that headache to others.

- Andy