Hi Alexander,
On Sat, Dec 31, 2011 at 03:41:04PM +0400, Alexander Polakov wrote:
> 1) dumb: check for Alt, Ctrl and Super(aka Mod4 aka Win) keys release
I do confirm your patch does the job, and works for me.
> 2) a little bit smarter: we can extract keybinding search code from
> handle_keypress
.
If this solution is ok, I can clean it a little bit and remove the keyrelease
handler and the altpersist member of struct screen_ctx.
Any comments?
Luis Henriques
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
This patch fixes an error when building the kernel with GPROF. Here's the
error:
1: warnings being treated as errors
../../../../kern/subr_prof.c:102: warning: no previous prototype for
'sysctl_doprof'
../../../../kern/subr_prof.c: In function 'sysctl_doprof':
../../../../kern/subr_prof.c:112: w
On Wed, Jun 30, 2010 at 04:08:17PM -0600, Theo de Raadt wrote:
> > Eventually there are usage scenarios where setting the maximum
> > performance to 50% (or whatever value) may make sense -- if you want to
> > save some power, for example. Anyway, I was just trying to make sure
> > everyone unders
On Wed, Jun 30, 2010 at 01:46:55PM -0600, Theo de Raadt wrote:
> > For example, if I am compiling the kernel, my laptop will overheat and
> > shutdown. So, I need to run apm -L in order to keep the temperature
> > lower.
>
> Balony. What you are facing is that the acpi throttling code is not
> h
On Wed, Jun 30, 2010 at 03:34:14PM -0400, Ted Unangst wrote:
> On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques wrote:
> > Probably, a silly question, but here it goes:
> >
> > With this patch, I will not be able to set the perflevel to, say, 50% and
> > keep the sy
they are not!), we should
also have a mechanism to disable this code (either at runtime or compile
time).
If I completely missed the point of this patch, just ignore me :-)
--
Luis Henriques
On Wed, Jun 30, 2010 at 02:32:26PM -0400, Ted Unangst wrote:
> I like this one better. Slow down the p
ing very difficult for me to get more envolved on
because 1) I do not have the hardware for testing and 2) I do not have
the knowledge on wifi network cards.
(btw, have you tried the latest patch I sent?)
--
Luis Henriques
Hi,
I'm attaching a patch I've been using for a couple of weeks now. Can
anyone give it a try? As usual, no guarantees -- it may crash your
system, so be careful.
Just let me know of any successful/unsuccessful story.
--
Luis Henriques
Index: dev/i
Hi,
Here's another patch with a couple of changes since the last one. Not
sure how this will make any difference to the cards that were not working
with previous versions, but hopefully there will be some changes.
Please let me know if this works for you.
Alexander: sorry for the delay on sendi
>> On 2010/04/28 18:41, Luis Henriques wrote:
>> > Anyway, this gave me the chance to find some more differences between
>> > ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
>> > HAL_MODE_XR) were defined with the wrong values. See updated
On Thu, Apr 29, 2010 at 12:27:41AM +0800, Alexander Vladimirov wrote:
> On Wed, 28 Apr 2010 14:15:27 +0100
> Luis Henriques wrote:
> > Interesting. This is behaviour seems to be different from what
> > Alexander was seeing. Is this correct Alexander? I believe you
> > ref
On Wed, Apr 28, 2010 at 2:07 PM, Giovanni Bechis
wrote:
> On 04/27/10 19:34, Luis Henriques wrote:
>>
>> BTW, with my wifi card, it seems to make no difference whether the value
>> 0x0040 or 0x1000 is used. How the hell my card is working??? :-)
>>
> I tried your l
On Tue, Apr 27, 2010 at 10:59:21AM +0800, Alexander Vladimirov wrote:
> On Mon, 26 Apr 2010 20:59:45 +0100
> Luis Henriques wrote:
>
> > @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
> > /*
> > * Set misc registers
> > */
> &
On Tue, Apr 27, 2010 at 3:59 AM, Alexander Vladimirov
wrote:
> On Mon, 26 Apr 2010 20:59:45 +0100
> Luis Henriques wrote:
>
>> @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
>> /*
>>* Set misc registers
>>*/
>> + /
On Mon, Apr 26, 2010 at 05:04:49PM +0100, Stuart Henderson wrote:
> AR5424 14.2 phy 7.0 rf 10.2, WOR5_ETSIC
>
> ar5212.c:ar5k_ar5212_reset() resets tx queues.
> I inserted a printf as follows...:
>
> /*
> * Reset queues and start beacon timers at the end of the reset
> routine
>
On Mon, Apr 26, 2010 at 4:03 PM, Adam M. Dutko wrote:
> The previous patches you sent me off list gave me this:
> ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
> 10)
> ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address XX:XX:XX:XX:XX:XX
> I'm going to evaluate the new
On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy wrote:
> Hi Luis,
>
> Yes, that is correct. Do you need the rf value from the patched kernel?
> I basically patched the latest -CURRENT (cvs tree as of yesterday).
Ok, thanks. I just wanted to make sure the patch was identifing
correctly your card. The
On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote:
> Luis,
>
> I have an Asus EEE with uses an AR5424 chipset:
>
> ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 18 (irq
> 10)
> ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f
>
> I tried the
Hi,
here's another version of the patch. It includes the patch from Alexander.
Again, it has been tested on my hardware only and it is working.
WARNING: previous versions of this patch are known to freeze your system
so... make sure you really want to test it! However, the -current version
of t
Hi Alexander (and others),
I am attaching a new patch which merges your patch with another one
I have never sent to tech@ before. I shared this patch with some other
guys that were testing it, but I believe it's worth trying it again
with your modifications.
Could someone run a quick test? Agai
On Sun, Apr 25, 2010 at 03:25:03AM +0800, Alexander Vladimirov wrote:
> I actually did, your patch was the starting point, but I encountered "ath0:
> device timeout" errors while testing with both patches applied, so it still
> needs deeper research.
Great, thanks. That's valuable information ;-)
Hi Alexander,
I was wondering whether you tested this code + my original patch. I
just merged both patches and I'm still able to use my card.
However, with my card the code you added (function ar5k_ar2425_channel)
is not actually activated -- I follow into the default case where function
ar5k_ar
Hi Stuart
On Sat, Apr 24, 2010 at 11:03:21AM +0100, Stuart Henderson wrote:
> Luis, can you send the latest version of your diff please. There were
> at least two and I'm not sure which one people should be testing.
> Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works
> ok wit
s missing to have your card working. But it will be trial & error:
I send you a patch and you test it :-)
I'll try to get some time today or tomorrow to dive into the driver again.
--
Luis
> On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques wrote:
>
> > On Tue, Apr 20, 2010
On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko wrote:
> I have a card to test with and am trying to solve the problem on my eeepc
> laptop. Luis, are you still around and interested in working on this?
Yep, still around. But not sure how I can help without the actual HW.
Sometime ago I submited
On Thu, Mar 11, 2010 at 1:20 AM, Abel Abraham Camarillo Ojeda
wrote:
>
> Anyone knows what happened to this?
>
> ... or it just got lost in the mist?
I'm currently using a CVS head kernel patched with this. But since the
patch seems to benefit myself only (no one else has reported a
successfull u
On Wed, Jan 27, 2010 at 8:48 AM, Giovanni Bechis wrote:
> Luis Henriques wrote:
>>
>> If you're able to test this patch, please let me know if anything changed
>> from previous patch.
>>
> The wireless doesn't work but some error codes have changed, now hal
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote:
> Giovanni Bechis wrote:
> >Stuart Henderson wrote:
> >>On 2010/01/25 00:50, Luis Henriques wrote:
> >>>Re-sending with "cvs diff -upRN"
> >
> Unfortunately this diff doesn't
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote:
> Giovanni Bechis wrote:
> >Stuart Henderson wrote:
> >>On 2010/01/25 00:50, Luis Henriques wrote:
> >>>Re-sending with "cvs diff -upRN"
> >
> Unfortunately this diff doesn't
On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote:
> On 2010/01/25 00:50, Luis Henriques wrote:
> > Re-sending with "cvs diff -upRN"
>
> Wha, you mean I have to dismantle my AspireOne again and put the
> minipcie back in to test it? But last time I d
Re-sending with "cvs diff -upRN"
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 -
My wireless card is recognised as being a AR5424 by OpenBSD. Unfortunately,
it is a non-supported card. After some hacking, I was able to make it work
by using some code both from Linux and NetBSD device drivers.
After some initial doubts about licensing issues (I though the Linux code
was GPL b
33 matches
Mail list logo
